jgreener64
commented
4 years ago Looks like a good roadmap.
Thus the next step would be to implement Ewald summation. I think that implementing another summation method would be a test of how flexible the API is.
Sounds like a good next step, and probably quite tricky.
Regarding the design, GPU and differentiability compatibility should be taken into account. I think this would require some changes to the out-of-place part of the API (since it currently just uses the in-place one) to use broadcasting.
I'm aiming to have a PR up by the end of the week on Molly to discuss this.
what milestones do you think we need for this package before registration?
Up to you, it's your package, though it would obviously need registering before it became a dependency in Molly. I would also put some basic docs or a README before registering, and would finalise the name.
a name should be decided for the package
Yes, this isn't an easy one. The package will calculate energies as well as accelerations, and isn't necessarily specific to atomic/molecular systems. Particle is quite a generic word though. Suggestions other than the current name would be ParticleSummations.jl, ParticleEnergies.jl, ParticlePotentials.jl, PotentialSummations.jl and NBodySummations.jl.
SebastianM-C
The aim of this package is to factor out the implementation of the summation methods in computing forces and potentials in N-body problems. So far there is a preliminary implementation of some pairwise summation for the total acceleration in the system.
The next step would be to deal with the energy computation. This would imply adapting https://github.com/JuliaMolSim/Molly.jl/blob/6808c8b8223be5e4b8a15d4013698f0c96b9d91d/src/analysis.jl#L79-L112
in a similar way to how the acceleration computation was done.
The above mentioned energy computation doesn't take boundary conditions into account, so methods like Ewald are necessary. Thus the next step would be to implement Ewald summation. I think that implementing another summation method would be a test of how flexible the API is.
Another thing to consider would be to see if the two summation methods could somehow use the same underlying implementation in order to reduce code duplication.
Regarding the design, GPU and differentiability compatibility should be taken into account. I think this would require some changes to the out-of-place part of the API (since it currently just uses the in-place one) to use broadcasting. This should coordinate with the discussion in https://github.com/JuliaMolSim/Molly.jl/issues/16
Lastly, a name should be decided for the package (I'm not sure the current one is the best choice) and the package should be registered with the tests describing how the Molly integration could work (see the molly.jl test file). After the package is registered, Molly could switch to this package (and the tests of this package should be adapted to reflect any changes in the process).
@jgreener64 what milestones do you think we need for this package before registration?