Error cmd_info.json not created during Salmon depth estimation

[vincianem]

Hello,

I encounter an error during the depth coverage estimation of the assembly step that make my runs fail.

I got the following error message FileNotFoundError: [Errno 2] No such file or directory: '/shared/ifbstor1/projects/homoploid_speciation_in_ferns/2-captus/2-assemble/botrychium/15666__captus-asm/01_assembly/01_salmon_quant/cmd_info.json'

The directory was created but not the file and I cannot figure out why. Here attached are the slurm file and the salmon log. Could you please help me figure out what the issue is?

I am working on the IFB core cluster where Captus was made available as a module. I do not have the upper hand on software installations.

salmon.log

slurm.cpu-node-8.63937410.txt

Best wishes,
Vinciane

[edgardomortiz]

Hi Vinciane,

I checked both logs, and the only thing that comes to mind is that you ran out of space and no new files could be written to that location? If this is not the case, please try deleting the assembly folder for that sample only /shared/ifbstor1/projects/homoploid_speciation_in_ferns/2-captus/2-assemble/botrychium/15666__captus-asm and running again the exact same command. Samples already assembled will be skipped, this one will be re-assembled and salmon will run again.

Sometimes HPC storage behaves strangely and it slows down to a crawl...

Let me know if this helps...

Edgardo

[vincianem]

Hi Edgardo,

I use only 400 GB over 10 TB, then it cannot not be a storage issue.

I just tried your proposition by deleting the assembly folder of the concerned sample and running the assemble step again. Unfortunately, I got the same error with another sample. I had already tried to completely delete the assemble folder and restart the assemble from scratch but it did not change anything.

Could it be something else?

Best,
Vinciane

[edgardomortiz]

Hmm that is really weird, are you able to share sample 15666's reads for me to test?

[vincianem]

Sure, here you go: https://e.pcloud.link/publink/show?code=kZTJX3Zh4ob3aDqr6pyrfiTELSQeh33VmOy

The are hybseq data generated from the GoFlag probes.

[edgardomortiz]

Running the sample now..., in the meantime, could you share the file captus-assemble.log too?

[edgardomortiz]

Very strange, the sample was assembled without error, maybe I can find more clues in the log.

Also, I always wanted to include GoFlag within Captus, where can I get the targets? it would be nice to offer them as an option besides Angiosperms353

Edgardo

[vincianem]

Thank you so much for your help!

Of course, here is the captus-assemble.log file.

captus-assemble.log

It would be amazing to have GoFlag targets in Captus. I do not know where to get the full target set, but you may ask Weston Testo (wtesto[at]uvm.edu).

Best,
Vinciane

[edgardomortiz]

Hi again @vincianem ,

I tried running the same version as you (1.1.0) with --max_contig_gc 60 and everything worked nicely. I am testing on Mac but I imagine Linux will behave the same (I will try to run it in a Linux machine too).

Looking at your command I can see the computer you are using has 56 cores and 256gb of RAM, I guess you are sharing computation with others. Maybe other programs are using a lot of RAM and this interferes with Salmon?

Another recommendation, if you can only use 12 cores, then use --concurrent 1 or at most --concurrent 2, to dedicate more cores per individual assembly. However this wouldn't affect Salmon because it will use the 12 cores per sample. In short, I can only think that is a RAM issue and other programs are competing for RAM when Salmon is running. Also, try using the latest Captus 1.6.1, I remember fixing some Salmon issues at some point (however I ran version 1.1.0 and it worked correctly).

This error is very weird, I hope the RAM can solve it... next thing I will try is v1.1.0 in Linux

Edgardo

[edgardomortiz]

I figured it out!

I installed Captus 1.1.0 in our supercomputer, the Salmon version that came with it was salmon 1.10.3 h45fbf2d_5, then I tried to run manually Salmon and I got a segmentation fault with your data.

The solution is to upgrade the Salmon build (with your current Captus environment activated):

conda install -c bioconda salmon=1.10.3=hb7e2ac5_1

That specific build of Salmon seems to work correctly with your data, let me know if this fixes the issue so I can document it in the help.

Also, Salmon gave me this warning (possibly the reason it was failing in other builds!):

[2026-02-10 18:34:25.349] [jointLog] [warning] 0.0351079% of fragments were shorter than the k used to build the index.
If this fraction is too large, consider re-building the index with a smaller k.
The minimum read size found was 21.

Which means that too many reads ended up being shorter than k=31 (the k size for the index in Salmon) after cleaning, I will see how I handle this in the next version of Captus, thanks for reporting the issue...

Edgardo