Should we pass more properties (e.g. velocities, step number) to force/potential_energy?

[jgreener64]

Currently to define force/forces and potential_energy for in-built and custom interactions we have:

• force(inter::MyPairwiseInter, vec_ij, coord_i, coord_j, atom_i, atom_j, boundary, special=false) for pairwise interactions.
• force(inter::MySpecificInter, coord_i, coord_j, boundary) for specific interactions, 2-atom in this case.
• forces(inter::MyGeneralInter, sys, neighbors=nothing; n_threads=Threads.nthreads()) for general interactions.

There have been requests to add velocities (#148 and @rkurchin) and step number (@noeblassel) to this. One reservation about adding step number, which can be used to apply time-dependent forces, is that it would mean simulate!(sys, sim, 100) is different from simulate!(sys, sim, 50); simulate!(sys, sim, 50; run_loggers=:skipzero) since the step counter resets. Maybe that is okay, though.

I can also see the value of passing the current forces to the general interactions to allow things like force clipping. This would mean the order of general interactions in the tuple becomes important, but that is okay if documented.

Possible new scheme:

• force(inter::MyPairwiseInter, vec_ij, coord_i, coord_j, atom_i, atom_j, boundary, special=false, vel_i=nothing, vel_j=nothing, step_n=nothing) for pairwise interactions.
• force(inter::MySpecificInter, coord_i, coord_j, boundary, vel_i=nothing, vel_j=nothing, step_n=nothing) for specific interactions.
• forces(inter::MyGeneralInter, sys, neighbors=nothing, current_forces=nothing, step_n=nothing; n_threads=Threads.nthreads()) for general interactions.

Adding these arguments on to the end as above could be non-breaking with default functions defined. But I'm also tempted to move the lesser-used coord_i, coord_j to before vel_i in the pairwise case, which would be breaking.

Let me know any thoughts, and any other properties that could be added. Time step is probably a no since not all simulators define it.

[ehsanirani]

Related to this, have you considered designing the possibility of passing properties other than velocities in the future? For example, in many cases, particles can have orientations, and being able to pass this information to pairwise forces would open up many applications for Molly.jl in Active Matter and Granular Matter physics, for example.

[jgreener64]

It would be good to hear the properties people are interested in. It would even be nice to pass arbitrary properties, but the issue is how to calculate them in the simulator to pass them to the interaction functions.

I guess you could also store orientations in the atom type, which would make them available in the interaction function, but then the question arises of how to update that property over the simulation.

[jgreener64]

We may also want to think about passing the zero force/energy to these functions. At the minute there is a clunky setup where for forces we define the units in the struct and then strip the coordinates to get a zero vector. This means more setup and likely has performance implications.

[ehsanirani]

It would be good to hear the properties people are interested in. It would even be nice to pass arbitrary properties, but the issue is how to calculate them in the simulator to pass them to the interaction functions.

I guess you could also store orientations in the atom type, which would make them available in the interaction function, but then the question arises of how to update that property over the simulation.

One idea would be to allow the user to define and have multiple simulators. One could be a classic simulator, and the other one could take care of the additional atom properties. For example, one could define a simulator to just integrate over orientation. It would also be powerful to be able to give the atom-type properties as arguments to the simulator. This way, built-in integrators like Langevin could be used for updating orientation. I think JAX-MD gives you this freedom.