Closed KRiedmiller closed 1 year ago
Conceptually, I would prefer to keep the config focussed on the actual simulation and have analysis as something separate. Though maybe an analysis may want access to the original config. This could be done either by re-supplying the yaml file or through loading a checkpoint, which we write anyways. Maybe the latest checkpoint could be marked specially?
I see why a certain plugin may want to to also bring additional analysis, but maybe those should be separate from KIMMDY itself. I would stick to the unix philosophy and just make sure kimmdy writes sensible and easily readable outputs and maybe provides additional api endpoints similarily to the --concat
option and then have analysis as separate modules/functions/scripts or in some special cases also kimmdy command line options.
The config tells Kimmdy and the reaction plugin what to do. If now only the plugin is needed, the config api/syntax does not need to change, it is just a subset of a KIMMDY config. In fact, I suggest not to change the config, all functionallity is there already.
I do not talk necessarily about special analysis like additional plots, but running the reaction plugin a single time. To make use of the output, the plugin then can present its output in a nice way.
More context is a simulation run in a different software than gromacs, like Genesis Jaewoon talked about. After such a run, you might want to query a single homolysis event, without whole KIMMDY.
To your second point, the plugins are separate to KIMMDY, and the analysis is special to this plugin, so it should bring its own analysis with it.
ok, sounds good
The ReactionPlugins could be used for analysis of existing MD runs. We could implement loading of trajectories in two ways