Stability of the dump command?

[karel-brinda]

Hello, thanks a lot for the dump functionality. This is actually currently a very useful feature for us and we've been using it across projects.

Is there a chance the command could be better documented in the README?

Also, can it be considered stable by now? (For context, we used to use it with the -o option, but this seems to have disappeared in some of the recent updates. At least this is what I believe to have happened, as with the bioconda-installed Fulgor some of our pipelines stopped to function correctly :).)

[karel-brinda]

Also, was there any fundamental change in the export command in terms of unitigs and colors (e.g., a redefinition of what a unitig is)? Because with our small toy dataset, we now see different statistics (not sure with which Fulgor update this changed; cc @vercah):

@@ -1,5 +1,5 @@
 k=31
 num_colors=10
-num_unitigs=287
-num_color_sets=29
+num_unitigs=297
+num_color_sets=30
 num_kmers=25180

[Alessio-Campa]

Hi Karel 😄

For context, we used to use it with the -o option, but this seems to have disappeared in some of the recent updates.

This is because the Fulgor version we loaded on Bioconda was v4.0.0. I assume you were using one of the latest commits on the main branch, so using the bioconda release could have actually been a downgrade for you.
We've recently published version v4.1.0 on Bioconda. Have you tried using that? All indices built with v4.0.0 should be compatible. Let us know!

P.s.: I just noticed that the arm compilation failed on the conda servers. I will fix it ASAP.

[karel-brinda]

Hi @Alessio-Campa,

Thanks for your answer.

so using the bioconda release could have actually been a downgrade for you.
That's actually possible :).

Do you have any idea why the number of unitigs and color sets might have changed?

[Alessio-Campa]

Off the top of my head, no. I was not able to find differences from the last commit on main and v4.0.0 that would explain this behavior. Which commit was used to get the "original" number of unitigs/color?

Was the index built from scratch before the output changed, or was it the same index?
I don't know the exact details, but different runs of GGCAT can produce different dBGs, with more or fewer k-mers, which would explain the difference in both unitigs and color sets.

[karel-brinda]

Thanks for the confirmation. I will go thoroughly with @verca-h through the changes on our side, if some of the toy things hasn't changed.

We upgraded many things at once, so I currently cannot pinpoint it to one single thing, yet. There were also changes in the minimizer size parameter, etc.

[rob-p]

I can confirm that there is indeterminacy in at least some versions of GGCAT (algbio/ggcat#24). It's always small, but it implies that it does not always produce exactly the minimal unitig set, and you can see variance between runs (though it will always produce a unitig set). However, I don't know if we are using a version where this is supposed to be fixed or not.

[karel-brinda]

@rob-p Rob, thanks a lot for this comment! This is actually really helpful – likely this is exactly what's going on.

How to make sense of the resulting unitigs? Are they just split at places they shouldn't be (i.e., technically still unitigs, but non-maximal)?

[rob-p]

Hi @karel-brinda,

Yes; that is correct. The unitigs are still correct unitigs, they are simply not maximal. This happens due to non-deterministic thread contention in the color assignment stage. At least before the update applied in the linked issue, the GGCAT authors noted this as a deliberate design decision rather than as a bug (i.e. to avoid locking in the high-thread context, they were willing to allow a small degree of non-maximality in the resulting unitigs).

[karel-brinda]

Great, thanks for the details. So the invariant to always test / track as a part of all the guardrails and tests will be the number of kmers instead of unitigs and colors…

…

Sent from my phone

On Wed, Apr 8, 2026 at 7:31 PM Rob Patro ***@***.***> wrote: *rob-p* left a comment (jermp/fulgor#79) <#79 (comment)> Hi @karel-brinda <https://github.com/karel-brinda>, Yes; that is correct. The unitigs are still *correct* unitigs, they are simply not maximal. This happens due to non-deterministic thread contention in the color assignment stage. At least before the update applied in the linked issue, the GGCAT authors noted this as a deliberate design decision rather than as a bug (i.e. to avoid locking in the high-thread context, they were willing to allow a small degree of non-maximality in the resulting unitigs). — Reply to this email directly, view it on GitHub <#79 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACC7KJRPOBBFJY5BR4XZ7SD4U2EH3AVCNFSM6AAAAACXPHFYUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMBYGE3TKOJUGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Alessio-Campa]

@karel-brinda did you try with the 4.1.0 release?
If the tools work as expected (i.e. there is the -o option in dump), I will mark the issue as solved.

For the num_unitigs/num_color_sets mismatch, I think there isn't much we can do...

[vercah]

Hello, yes, the bioconda release works with the -o option now (at least for me). Thank you and Rob for the explanation!

[karel-brinda]

Thanks for all the work!!

For the num_unitigs/num_color_sets mismatch, I think there isn't much we can do...

Probably the only thing is to document this in the readme that both of these numbers can be overestimated, especially for toy datasets.

[jermp]

Yes, will add a note in the readme.

[jermp]

Added description of the dump output format as of 70a9896.
(I've also included an extra field to .metadata.txt with the number of kmers which might be useful to know.)