Organization of some fields is confusing #3
Description
Organization of some fields in the output "metadata" file is confusing or downright wrong. For instance, parameters for "awh" are included in the "qm-opts" section, i.e. Quantum Mechanics Options, but AWH has nothing to do with quantum mechanics. The same can be said about "constraint-algorithm", "pull", "rotation", "continuation" and actually most of the fields in this section.
In fact, I don't think it makes sense to report all the parameters from the TPR file (such as seed for the random number generator, all indices of atoms involved in various pull groups and especially not the TPR file buffer size), but I understand that it may be safer to extract all the possible information, in case some of it may eventually be needed. Note that the data reported in the JSON/YAML are nonetheless not sufficient for performing a reproducible simulation, but I believe that is not necessary the goal of the tool.
However, if the goal is to be as general as possible and include all the possible information that may potentially be useful, it would be nice to have an option to specify objects (in the "simulated object" section) other than proteins and ligands, for instance information about a simulated membrane (its composition) or a nucleic acid.
In the "Solvent" section, wouldn't it make more sense to report the concentration of ions, rather than the concentration of solvent? Why is the water model specified in a completely different section than "Solvent"?
I wouldn't care if this were a simple tool that is optional to use, but knowing that EOSC may want to use this as the STANDARD and compulsory tool for extracting and annotating data from Gromacs simulations, this really really needs more work.
Final note: do the authors realize that using a custom version of gmx dump means that any time a new parameter is added to a Gromacs TPR file (frequently!), they will have to update their own custom Gromacs version and the users using the CLI application will have to reinstall it so that they can continue annotating their data? Wouldn't using and parsing the output from the default gmx dump utility be much more robust and user-friendly?