That's already way better than the simple and naive version ! On my
computer, this gives me something 4x slower than serial LAMMPS code.
I'll try to integrate this into the package. It will need changes in the
data structures, but this is worth it !
I'll have to think a bit about how I can organise the data for
parallelism. The basic idea is to have every cell on a different
processor, isn't it ?
Bests,
Guillaume
Amuthan a écrit :
Hi Guillaume: I've added the serial version of the linked-cell MD code
here: https://gist.github.com/Amuthan
The code is pretty basic and needless to say, a lot more functionality
needs to be added (though I should admit that I'm more interested in
extending this code to a parallel version than to develop it as a
full-fledged MD package). I've made a few changes to make it work for
your benchmark; I didn't spend too much time optimizing it, but the
current version is just 7 times slower than the LAMMPS code. I guess
someone with a better understanding of Julia can optimize it further.
Let me know if you have any comments or questions or suggestions for
improvement.
Cheers,
Amuthan
On Wed, Jan 28, 2015 at 7:48 AM, Luthaf <[email protected]
<mailto:[email protected]>> wrote:
Hi Amuthan,
The current code uses the direct sum because this was the easiest
algorithm to implement, and your understanding is totally correct.
Adding other algorithms is a piece of cake: it is as easy as
subtyping `BaseForceComputer` (I could not came with a better
name), and providing a `call` method.
So I am planning to add at least (serial) Verlet neighbor lists
for the forces computations, and maybe some parallel code.
But I don't know a lot about parallel methods in MD, and I still
have a lot to learn about it. It would definitively be very nice
to have it !
I think that only a few changes are needed to use julia parallel
framework in the package. All the data are stored in objects of
type Array3D, which could be modified to use DArray instead.
I am open to change the internal data structure if this can
improve the performances.
Is your neighbor list code available somewhere ? I am interested
in reading it.
Cheers,
Guillaume
Amuthan A. Ramabathiran a écrit :
Hi Guillaume:
This looks good -- thanks for the package! I have a basic
question regarding the force computation: I had a quick look at
the code and it appears to me that the current code uses an
O(N^2) algorithm (direct sum) for this. Is my understanding
correct? Software like LAMMPS use very efficient algorithms for
short and long range potentials and this might possibly account
for the fact that the benchmark is 80x slower.
I had developed a serial MD code using neighbor lists last year
and I'm currently in the process of parallelizing it to study the
suitability of Julia for developing (reasonably) parallel
research codes. Is parallelization something you're looking into?
I would be very interested in hearing about this. Thanks!
Cheers,
Amuthan
On Tuesday, January 27, 2015 at 2:46:59 PM UTC-8, Luthaf wrote:
Hi julians !
I am very happy to announce the release of Jumos, a Julia
package for molecular simulations.
You can find the code here:
https://github.com/Luthaf/Jumos.jl, and the documentation is
hosted by readthedocs : http://jumos.readthedocs.org/en/latest/.
This package aims at being as extensible as possible. Every
algorithm is a type that can be subtyped and changed at
runtime, during the simulation.
This makesit easy to write new algorithms, experiment with
them, and combine algorithms in all the fancy waysyou can
imagine.
Presently, only molecular dynamic is implemented, but I am
planning to add energy minimisation, and trajectory replay
from files (maybe monte-carlo simulations if I find some
time). A handful of tools are alreadyimplemented :
- Velocity-Verlet and Verlet integrator;
- Lennard-Jones and Harmonic potential;
- User-defined potentials;
- RDF and density profile analysis;
- Berendsen thermostat;
- Velocity-rescale thermostat;
- Temperature and energy computations.
And a lot more are planned:
https://github.com/Luthaf/Jumos.jl/issues.
If you want to help, contributions are very welcome ! Just
pick up an issue or create a new one as a feature request.
The first benchmark (against LAMMPS) givesme a speed 80 times
slower than LAMMPS. This is already great for a dynamic
language, but there is still room for improvement !
Any feedback on the implementation is also very welcome.
Regards
Guillaume
PS: Whatdoes the ANNin the titlemean ? It seems to be
everywhere, but I don't have any clue about its meaning
