If we see a FASTG file containing an edge declaration like
>EDGE_1_length_9_cov_4.5:EDGE_3_length_5_cov_16.5',EDGE_3_length_5_cov_16.5';
ATCGCCCAT
... then, as of pyfastg v0.1.0, pyfastg's parse_fastg() function will throw an error saying that Node 1+ has duplicate outgoing adjacencies. The rationale for this behavior is that I haven't seen any SPAdes-dialect FASTG files that contain "parallel adjacencies," and I'm not sure if supporting these would be useful for anyone. (Also, the whole "edge and adjacency" paradigm of FASTG files means that defining multiple "adjacencies" between the same two edges becomes kind of hazy.)
That being said: if these sorts of graphs can exist in practice, then I think it should be fairly simple to modify pyfastg to support them (we would just change our return type from nx.DiGraph to nx.MultiDiGraph). If you (whoever is reading this) has any thoughts on this, please comment below.
If we see a FASTG file containing an edge declaration like
... then, as of pyfastg v0.1.0, pyfastg's
parse_fastg()function will throw an error saying thatNode 1+ has duplicate outgoing adjacencies.The rationale for this behavior is that I haven't seen any SPAdes-dialect FASTG files that contain "parallel adjacencies," and I'm not sure if supporting these would be useful for anyone. (Also, the whole "edge and adjacency" paradigm of FASTG files means that defining multiple "adjacencies" between the same two edges becomes kind of hazy.)That being said: if these sorts of graphs can exist in practice, then I think it should be fairly simple to modify pyfastg to support them (we would just change our return type from
nx.DiGraphtonx.MultiDiGraph). If you (whoever is reading this) has any thoughts on this, please comment below.