Open subwaystation opened 1 year ago
My takaway here is:
odgi extract
to odgi sort
: odgi extract -i graph.og -o - -r <CHROM:START-END> -d <INT> | odgi sort -i - -o graph.Y.O.og -O
should be done as default in order to circumvent the last disk space issue. -d
has to be set in order to retrieve a graph giving a more global answer.
Hi @AndreaGuarracino,
I was trying to extract
grch38#chr1:13104252-13122521
from the Chr1 HPRC pangenome graph. However, I ran into lot's of trials and errors until I somehow got what I wanted. Surprisngly, theodgi extract
output occupied quite some disk space sometimes. More details below.Fetching the data
1st round
How can it be that before optimization the graph occupies ~1GB on disk? Let's take a look at the actual subgraph we got.![chr1 test d100 og O](https://user-images.githubusercontent.com/10184961/220875578-e1b8febc-8ecf-4d67-8635-ef31aa334db5.png)
This doesn't look so bad, but all paths are somehow scattered, so we miss the big picture, therefore I did lot's of trials to understand what's going on.
2nd round
3rd round
-d 100000
so I can catch all the missing path parts.4th round
-E
? Here we go.....5th round
6th round
Now the resulting graph is much smaller on disk, great! Locally, this is as best as it can get. However, we still lack the overall picture.![chr1 test d100 og Y O](https://user-images.githubusercontent.com/10184961/220879865-c2d8849c-7cbb-455d-aee8-1f6293b9c572.png)
7th round