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]> 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 makes it easy to write new algorithms, experiment with them, and
>> combine algorithms in all the fancy ways you 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
>> already implemented :
>>      - 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) gives me 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: What does the ANN in the title mean ? It seems to be everywhere,
>> but I don't have any clue about its meaning
>>
>>
>

Reply via email to