Thermodynamic ensembles in input files

[Luthaf]

Here is an idea that I had about the input files. Currently, the input system is quite complex and the user need to choose a lot of parameters. This is good, because some people will like to use this. But it make the code a bit harder to use for newcomers.

How about having some kind of alias system in the input files, allowing to select thermodynamic ensembles with a sensible set of default?

For example,

[simulations.propagator]
type = "MolecularDynamics"
ensemble = {name = "NPT", pressure = "500 bar", temperature = "300 K"}

Would expand to something like this, picking algorithms and parameters values:

[simulations.propagator]
type = "MolecularDynamics"
timestep = "1 fs"
integrator = {type = "BerendsenBarostat", pressure = "500 bar", timestep = 1000}
thermostat = {type = "Berendsen", temperature = "300 K", timestep = 100}

Which algorithm would be used could change from one release to another, and to make sure simulation conditions are properly documented, the code would print the equivalent input somewhere when expanding the alias.

The integrator parameters (in MD) or the moves (in MC) would be as generic as possible, and thus not generate the fastest possible simulation. But it can get people started more easily.

[antoinewdg]

I think this is all around a good idea.

the code would print the equivalent input somewhere when expanding the alias.

This is really important, having some "noob friendly" feature one can not easily map to the extensible use case is extremely frustrating.

[g-bauer]

While it would be good for beginners, I am a little torn about such a feature. The outcomes of simulations heavily depend on the parameter used - not just the thermodynamic state but also numerical aspects (time steps, acceptance rates, etc.). The user should be aware of the impact of every parameter he/she has to specify. I don't think we should take the burden off of users by giving them "black boxes" to use without thinking about those parameter (they could make no sense in their case).

I'd prefer to have more in depth documentation, examples and tutorials to make those aspects visible to (new) users. IMO new users have the same effect by "copy and pasting" the example input files from docs and examples.

But I also see the need for lowering the barrier for new users and writing extensive docs and examples is (more) time consuming. Just wanted to throw this aspect into the discussion. Anyways, if we decide to implement such a feature, there should be a log file in which all used parameter are written.

[antoinewdg]

Well what @g-bauer says also makes sense (I know I'm absolutely not helping by just agreeing with everyone). At least we all agree that a good logging with the actual parameters used is vital if we go this way.

About the fact that noob-friendly docs would be another (and admittedly better) way to help new users in, being much "noobier" than almost everyone you can expect to use lumol, I'd be willing to proof read such docs if they were to be written.

[antoinewdg]

Maybe having a doc with the reasonable defaults we would have used (that can just be copy pasted), with a good explanation of why and when these are good results would be a good start ?

[g-bauer]

About the fact that noob-friendly docs would be another (and admittedly better) way to help new users in, being much "noobier" than almost everyone you can expect to use lumol, I'd be willing to proof read such docs if they were to be written.

Thanks! It would also be a huge help if one (you? 😄 ) could identify parts of the docs that need more detail or are missing. I am currently writing a tutorial for extending the MC part (write your own move) and a tutorial for implementing a potential function. I'd love to get some feedback on those as well.

[antoinewdg]

I'd love to get some feedback on those as well.

Where can I read them ?

I'll start to take notes when reading the docs to identify weak spots.