fix radius of gyration normalization
Issue based off of the data from Elsing Data (traj_full)
Problem:
In short, the calc.radius_of_gyration[rg_index]
was "out of range".
"root":{
"errors":string"normalizer failed with exception"
"event":string"process failed"
"proc":string"Entry"
"process":string"process_entry"
"process_worker_id":string"Tkjrys0MQvqnOyF6g5q8Iw"
"parser":string"atomisticparsers:gromacs_parser_entry_point"
"error":string"list index out of range"
"normalizer":string"ResultsNormalizer"
"step":string"ResultsNormalizer"
"logger":string"nomad.processing"
"exception":string"Traceback (most recent call last): File "/opt/venv/lib/python3.12/site-packages/nomad/processing/data.py", line 1548, in normalizing normalizer(self._parser_results).normalize(logger=logger) File "/opt/venv/lib/python3.12/site-packages/nomad/normalizing/__init__.py", line 79, in normalize self.normalizer.normalize(self.archive, logger) File "/opt/venv/lib/python3.12/site-packages/nomad/normalizing/results.py", line 138, in normalize self.normalize_run(logger=self.logger) File "/opt/venv/lib/python3.12/site-packages/nomad/normalizing/results.py", line 238, in normalize_run properties, conv_atoms, wyckoff_sets, spg_number = self.properties( ^^^^^^^^^^^^^^^^ File "/opt/venv/lib/python3.12/site-packages/nomad/normalizing/results.py", line 1264, in properties rg = self.rg() ^^^^^^^^^ File "/opt/venv/lib/python3.12/site-packages/nomad/normalizing/results.py", line 1050, in rg sec_rg = calc.radius_of_gyration[rg_index] ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ File "/opt/venv/lib/python3.12/site-packages/nomad/metainfo/util.py", line 135, in __getitem__ return super().__getitem__(item) ^^^^^^^^^^^^^^^^^^^^^^^^^ IndexError: list index out of range"
"timestamp":string"2025-01-02 11:05.18"
"level":string"ERROR"
}
Solution:
The out of range is due to a discrepancy between the system and calculation lists. In this case, only a single system is stored, but the outputs (calcs) are stored throughout the trajectory. We can only calculate the Rg's for calcs which have a corresponding structure. Thus, the solution is to add a check for a system_ref
within the calc section.
@g-bernadettemohr Please note the solution, and plan to contact Elsing with an update once it is merged. For the secondary problem -- recall, this had to do with an empty atomsgroup during the calculation of the rdfs -- I found that this is not a problem with our code. This is an issue with the file setup. In the traj_nosolv example, they removed the solvent (TCM) from the trajectory, but they uploaded the "full" tpr file. If they want to trim out the solvent, they need to create a new tpr file without the solvent, or else the MDAnalysis moltypes, fragments, segments, etc. get all messed up because of the inconsistency. Could you try creating a new .tpr file by removing the TCM mol definitions in the top and then test if this secondary problem is fixed as I predict?
@himanel1 Could you provide a brief check to my fix and give me the green light?