extract_pdb: failure to read decoy from silent-file

[mandar5335]

Hi,

I am trying to extract PDB after rna_denovo run. RNA sequence length and secondary structure length is 125 and correctly given as input.
I used pre-built rna helices as an input to rna_denovo along with sequence and structure.

I am first time encountering this kind of error and I am not sure about origin of it.

Command used:
extract_pdbs.mpi.linuxgccrelease -in:file:silent ../simple_cycle.out -tags cat all_str_tags

The error details are as follows:

Version : 2023.45+release.a6d9ba8
##########################################################
core.io.silent.SilentFileData: (0) Reading 86857 structures from ../simple_cycle.out
core.io.silent: (0) [ ERROR ] trying to index off the end of the secstruct array, idx is 126 secstruct_.size() is 125

[ ERROR ]: Caught exception:

File: src/core/io/silent/SilentFileData.cc:825
failure to read decoy S_057519 from silent-file ../simple_cycle.out

AN INTERNAL ERROR HAS OCCURED. PLEASE SEE THE CONTENTS OF ROSETTA_CRASH.log FOR DETAILS.

###########################################################

Looking forward to suggestions from experts and users.

Thanks,
Mandar

[mandar5335]

It seems like file is corrupted. Is there any tool to recover outfile?

[roccomoretti]

There's a -silent_read_through_errors option you can pass which will cause Rosetta to try to skip the corrupted structures and extract the structures it can.

Depending on what sort of corruption it has, you might be able to use grep and a text editor to pull out the data and de-corrupt it, but I'd probably only recommend that if there's a specific structure you really need.

I'll note that the most common cause of corrupted silent files is running multiple Rosetta processes that are all trying to output to the same silent file. That doesn't work, and the different processes will step on each other's toes. You either need to launch them with separate silent files you later combine together, or you need to use something like MPI where there's explicit coordination of silent file writing.

[mandar5335]

Thanks for your reply.

I could not grep the output file as I keep getting error:
grep: simple_cycle.out: binary file matches

I am using MPI version of rna_denovo as:

mpiexec -np 48 rna_denovo.mpi.linuxgccrelease -fasta rna_sequence.fasta -secstruct_file rna.secstruct -cycles 20000 -minimize_rna true -nstruct 10000 -out:file:silent simple_cycle.out > out.log

Do I need to add any specific option to rna_denovo to avoid file corruption in the future?

[vmullig]

You can use "grep -a" to force interpretation as ASCII. The binary silent format (which is really an ASCII file that uses a little trick to store 3N bytes of binary information in 4N bytes of ASCII data) may resemble a true binary file to grep. You can also try forcing Rosetta to interpret the file as binary, with "-in:file:silent_struct_type binary". On the off chance that the binary silent file was produced on a system with endianness different from the system on which you're reading, you can try "-in:file:force_silent_bitflip_on_read".

…

On Thu, Sep 12, 2024 at 11:42 AM Mandar Kulkarni ***@***.***> wrote: Thanks for your reply. I could not grep the output file as I keep getting error: grep: simple_cycle.out: binary file matches I am using MPI version of rna_denovo as: mpiexec -np 48 rna_denovo.mpi.linuxgccrelease -fasta rna_sequence.fasta -secstruct_file rna.secstruct -cycles 20000 -minimize_rna true -nstruct 10000 -out:file:silent simple_cycle.out > out.log Do I need to add any specific option to rna_denovo to avoid file corruption in the future? — Reply to this email directly, view it on GitHub <#157 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABACZUFYBCCEZ47GZ5NKQNLZWGY6VAVCNFSM6AAAAABN52EAYOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANRSG44TINY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[mandar5335]

Hi,

I tried possible combinations from suggestions. It seems like file is overwritten at some point and not sure what caused it.

Thanks @roccomoretti and @vmullig for answers.

/- Mandar