Make other properties time dependent (e.g. charges)

[pstaerk]

Is your feature request related to a problem?

My group is very interested in having the ability to make the charges time dependent.
We are simulating fluctuating electrodes (in LAMMPS), where the charge is treated as an additional degree of freedom.
Lammps trajectories enable you to output custom styles where e.g. the charge is also written for each timestep and to my limited knowledge this is possible in other simulation frameworks too.

Describe the solution you'd like

Ideally, the trajectory parser should be able to accept custom style descriptions (or guess them from the lammpstrj dump file's header) and then make the charge a part of the trajectory's attributes.
From looking at the parser's code this should not be too hard to add, but I am not sure how the hard change to the topology/trajectory backend would be.

[hmacdope]

The ts.data attribute can be used to hold arbitrary timestep associated data. You could always add the charges to that IMO.

See this line for an example of adding to it in the LAMMPS parser. :)

[pstaerk]

Thanks for this very helpful answer! :)

[pstaerk]

Is this something which could be included in MDAnalysis permanently? I have the impression that a number of people could use such a time-dependent charge reader (or a bit more flexibility in time dependent quantities).

[IAlibay]

So as you alluded to @pstaerk part of the issue is that our topology & trajectory framework really was built on the idea of "early generation" force fields where topology attributes like partial charge are static and the only things that change are the positions/forces/velocities.

Adding more attributes to the trajectory technically is possible, but would involve a lot of re-work, and as things currently stand would possibly lead to increased access costs to these topology attributes (or at the very least there's a computational cost associated with reading an array of data out of the timestep object). This is probably going to be problematic in the majority use case where time-dependent topology attributes isn't a thing that is really supported (I guess technically AMBER and GROMACS support AMEOBA and DRUDE respectively, but I'm not sure we can even deal with them properly at the moment).

@hmacdope's solution would be the simplest one, and adding the ability to read into ts.data if available would be a reasonable addition to the reader. I would likely support a PR that implemented this. Would you or anyone from your group be interested in contributing this? However, I can also see how this might be not so user-friendly / easily to deal with (as you would have two charge attributes, one in ts.data and one that is static in atoms.charges).

Allowing topology attributes to iterate is something that in the short term is probably not going to be very feasible in the short term I think, but I'll let @lilyminium add her thoughts here since she's more knowledgeable on recent changes to that part of the code.

[hmacdope]

Is this something which could be included in MDAnalysis permanently? I have the impression that a number of people could use such a time-dependent charge reader (or a bit more flexibility in time dependent quantities).

I would support a PR with this functionality, as we are generally trying to improve the flexibility of the LAMMPS parsers. :)

[hmacdope]

I should also mention in advance that I think the best way to do this is to support the general case, ie reading any additional column.

You can then specify additional columns as an argument to the reader.

[orbeckst]

If we have a trajectory reader that stores arbitrary data in the ts.data dict under a certain key, can we write custom attributes that look into ts.data[KEY][atom.ix]? Maybe it's not as performant as the native topology framework but it would provide a flexible path to time-dependent data and it also remains true to the original spirit of #363 to lookup data in individual attribute arrays.

cc @richardjgowers @lilyminium