Limitations

While gorder aims to provide accurate and reliable results, there are some known limitations and scenarios where it may not be suitable. The current limitations are as follows:

1. gorder cannot read TPR files generated with Gromacs versions older than 5.1.

   • Why is this the case? This limitation stems from the minitpr crate used to parse TPR files. The TPR file format evolves constantly, and supporting all ancient Gromacs versions is simply not feasible.
   • What can you do if your TPR file is this old? In most cases, the solution is simple: convert the old TPR file using a new version of Gromacs, i.e., run gmx convert-tpr -s old_file.tpr -o new_file.tpr. If converting a TPR file is not an option for you, you can instead provide a PDB file with a connectivity section or a GRO file along with a bonds file (see Using other input file formats).
   • Will this be addressed in the future? Older Gromacs versions will likely never be fully supported.

2. gorder only fully supports systems with orthogonal simulation boxes and periodic boundary conditions applied in all three dimensions.

   • Why is this the case? This limitation arises from the groan_rs crate, which provides only partial support for non-orthogonal simulation boxes. Handling periodic boundary conditions in such boxes is complex and not fully implemented at present.
   • What can you do if your box is not orthogonal? You must instruct gorder to ignore periodic boundary conditions. Then, provide a trajectory where the lipid molecules are whole, and perform the analysis as usual.
   • What can you do if your system is not periodic in some dimensions? In most cases, there will be no issue; however, such systems have not been tested, and artifacts may occur. You can try ignoring periodic boundary conditions while ensuring the lipid molecules are whole and verify if the results change.
   • Will this be addressed in the future? gorder is unlikely to ever fully support non-orthogonal simulation boxes, simply because they are not common in membrane simulations. However, better support for partially periodic systems might be added in the future.

3. gorder does not fully support the analysis of systems with multiple membranes.

   • Why is this the case? Handling multiple membranes is complex, and such systems are relatively uncommon. gorder is primarily designed for analyzing single-membrane systems. This does not mean you cannot use it for multi-membrane systems, but some features may not work as expected (see below).
   • What can you do if your system contains multiple membranes? If you are performing basic analysis with a static membrane normal and no leaflet assignment, no special action is required. However, be aware that order parameters from all membranes will be averaged into a single collective set of order parameters. If you are assigning leaflets, note that the only usable automatic classification method is the individual method. If you are using dynamic membrane normal calculation, ensure that the membranes are sufficiently far apart: specifically, farther than the radius value used in the membrane normal calculation. You can of course also select atoms from a single membrane for analysis, but make sure to consistently apply this selection across all relevant sections, particularly in dynamic membrane normal calculation.
   • Will this be addressed in the future? Will gorder ever support membrane-specific order parameter calculations? This is highly unlikely. Multi-membrane systems are rare, and membrane-wise analysis can be performed by running individual analyses with different atom selections. Since gorder is fast (and even faster when the trajectory is already cached), performing multiple runs should not be a significant issue.

4. gorder fails when analyzing XTC trajectories from simulations longer than 2,147,483,647 simulation steps. (Note that this corresponds to simulation length of roughly 4.3 μs at 2 fs time step.)

   • Why is this the case? This limitation stems from the molly crate used to parse XTC files (and partially from the design of XTC files themselves). The simulation step in an XTC file is a 4-byte signed integer whose maximum value is 2,147,483,647. If a higher step is reached, molly crashes with an error instead of overflowing like many other libraries. Read more here and here.
   • What can you do if your trajectory is this long? Remove the step information from your trajectory. A recommended approach is to use the step2frame tool, which generates a trajectory where step numbers are replaced with frame numbers. Use the converted trajectory as the input trajectory for gorder.
   • Will this be addressed in the future? Yes — either by fixing the issue in the molly crate or by allowing compilation of gorder without molly (which would, however, make gorder slower).