Implement Chop

[susan-garry]

Chop works! After cargo build --release, try something like fgfa -I ../tests/k.gfa chop -c 3 -l. -c 3 specifies that nodes are to be chopping into segments no longer than 3, and -l specifies that the output file should compute new links (at this time, it's still not clear to me what need we have for links, if any, but it would be easy to make computing links the default behavior or to always compute links). (Side note, slow_odgi does not compute links - do we care to change this?)

The basic algorithm for chop is as follows:

seg_map;     // map from old segments to their new, chopped counterparts
for each segment:
    chop into segments of size c or smaller
    if args.l:
         link the new segments together, from head to tail (i.e., in the forward orientation)
    update seg_map

for each path:
    new_path;
    for each step in path:
        for new_seg in seg_map(step.seg):
              append new_seg to our new_path
    add new_path to new_fgfa

if args.l:
    for link (A -> B) in old_fgfa:
        add a new link from
             (A.forward ? (A.end, forward) : (A.begin, backwards))
                 -> (B.forward ? (B.begin, forward) : (B.end ? backwards))

One weird note here: the implementation of chop is split between cmd.rs and main.rs. The brunt of the work is done in cmd.rs, but the logic for which aspects of our original graph to preserve is in main.rs. It's unclear that a nice fix exists; because our new graph is borrowing elements from a GFAStore created by chop in cmd.rs, ownership of the GFAStore must be passed to the main function in order for our new FlatGFA to be valid. The best fix may be to compute the FlatGFA in chop and return both the FlatGFA and GFAStore, but right now we do not.

[sampsyo]

AWESOME!! This looks really great. I have just a few low-level suggestions, if you're interested!

[sampsyo]

Maybe we should make these odgi versions match for the two jobs?

[sampsyo]

(See next comment.)

[sampsyo]

Might I suggest that we don't actually need to do this .og conversion? Seems like odgi works just fine reading directly from a GFA file, and eliminating this step would reduce the surface area of things that can break by one.

[sampsyo]

Fine to just delete this line.

[sampsyo]

For benchmarking purposes, I think we should probably omit the view and norm steps. This makes for a fairer comparison, where we just measure the time taken to do the data structure transformation and not the time to print out the results. (This of course means that we can't simultaneously check correctness, but I suppose that is probably best done separately.)

[sampsyo]

I think you have a utility method for this now (Span::new_empty())?

[sampsyo]

These could perhaps use comments to describe what they do and what invariants they maintain?

[sampsyo]

DEFINITELY not for this PR, but: I wonder if there's some kind of utility method that we can invent to help with this stuff. Impressionistically speaking, what we want here is...

let segs = seg_map[step.segment()];
flat.add_steps(segs.map(|s| Handle::new(s, Orientation::Forward)));

Like, we kind of want a way to do a map directly on a chunk of segments, without having to fiddle with the index math here. Maybe we can think of a clever way to make that look nice!

[sampsyo]

Could be a little shorter/clearer as:

let seg_id = match old_from.orient() {
  Orientation::Forward => chopped_segs.1 - 1,
  Orientation::Backward => chopped_segs.0,
};
Handle::new(seg_id, old_from.orient())

[sampsyo]

A similar simplification is probably possible here.