Netiquette · Download · News · Gallery · G-quadruplexes · DSSR-Jmol · DSSR-PyMOL
· Video Overview · DSSR v2.5.4 (DSSR Manual) · Homepage
-
When I analyze MD trajectories with the --nmr option, the runtime does not scale linearly with the number of frames as one might expect. For the same structure here are some benchmarks:
| n_frames | runtime (hh:mm) |
| 2500 | 1:00 |
| 5000 | 4:15 |
| 10000 | >15:00 |
This suggests to me that there is either some sort of memory leak or maybe the file writing is seeking to the end of the file at the end of each frame?
Here is my DSSR command:
~/software/x3dna-dssr -i=RNA_traj.pdb --nmr --json -o=dssr.json
DSSR version: 2.4.6-2024nov15
-
Hi,
Thanks for using DSSR and for posting your question on the Forum. I am aware of the issue you are describing. The initial design of the --nmr option allows for flexibility of user-selected frames/models (e.g., --nmr=3+5+6:9 as described in the User Manual). For each frame/model, DSSR re-reads the input file from the beginning, which causes the slowdown as you observed. There is no memory leak, as you can verify with valgrind or similar tools.
DSSR Pro version allows for sequential processing of all the frames in a single pass, which leads to faster performance (scale linearly with the number of frames).
Best regards,
Xiang-Jun
-
I see. That makes sense where the slowdown is coming from. For what its worth, in tools I've worked on in the past, when we need to do random-access trajectory reading, we first read through the whole trajectory once and make an index of the byte offsets for the start of each frame. That way you can jump to any arbitrary frame without having to search through the file each time.
-
It sounds like a good suggestion. I will think about it.
Funded by the NIH R24GM153869 grant on X3DNA-DSSR, an NIGMS National Resource for Structural Bioinformatics of Nucleic Acids
Created and maintained by Dr. Xiang-Jun Lu, Department of Biological Sciences, Columbia University