derived library?

[mlund]

Hi Martin, I just stumbled over your neat c++ library which is quite close to that I’d like to develop for monte carlo simulations of molecules. Currently I’m using std::vector<particle> for our codes, see i.e. https://github.com/mlund/faunus.

Ideally I’d like the following:

1. dynamic number of particles for i.e. Grand Canonical ensemble (erase/insert functions for a range of particles (i.e. molecules), mem. handling)
2. STL-like access and iterators
3. vec3 should be based on the Eigen matrix library
4. no boost dependence, but c++11 OK.
5. header only, preferably
6. direct data access to i.e. positions for copying/referencing to python or other libraries

Should you have any input or ideas on how to modify your code in that direction, I’d very much appreciate it. Best, Mikael

[martinjrobins]

Hi Mikael,

Thank you for your interest, molecular dynamics is definitely one of the areas targeted by Aboria so I'm keen to get it involved in codes like yours.

In general, most of the points you bring up are already covered by Aboria, or would be simple to add. Aboria has two APIs, one based around an STL-compatible container class Particles, and the other being a symbolic API based on expression templates. It sounds like the first API would suit your needs well.

1. dynamic number of particles: This is already implemented and Particles has the standard insert, erase, push_back and pop_back functions required of an stl container https://martinjrobins.github.io/Aboria/Aboria/Particles.html
2. STL-like access and iterators: This is already implemented. For examples see here: https://martinjrobins.github.io/Aboria/aboria/quick_start.html#aboria.quick_start.looping_through_the_container
3. vect3 based on Eigen: This should be easy, at least for the STL API. vect3 used to be a typedef of the Eigen vector class, but I changed it to a custom class during debugging because I didn't like the long compiler errors due to Eigen's expression templates. However, note that I am also using expression templating for the symbolic API, so I don't know how these will interact
4. removing boost would probably not be possible unless you also removed a fair bit of the functionality, I use the Boost MPL library for the get and set functions to get/set particle variables, and I use the Boost Proto library for the expression templates in the symbolic API. I use it in a few other areas, but these are minor and could be removed. However, all the boost libraries that I use are header-only, so these could be packaged with your code along with things like Eigen that you already have.
5. header only. Aboria is 100% header only
6. direct data access: This is straightforward. You have access to all the data through the STL compatible container, and wrapping this up in Python is easy. See this repo https://github.com/martinjrobins/aboria_init for an example of how to do this.

Hope this helps.

cheers, Martin

[martinjrobins]

Hi Mikael,

How did you end up with this. Did you end up using Aboria for your code? If you have any more questions please let me know, and if not I'll close this issue.

cheers, Martin

[mlund]

Hi Martin, Thanks for your explanations back in 2016 -- I just noted it was the first issue posted :-) I still haven't switched to Aboria, but it certainly looks attractive and well developed. The number one reason is the extensive refactoring required to my code, and secondly I'd ideally like to avoid Boost but, as you said, the required headers could be bundled in. Now that most compilers have decent support for c++17, could this be used to replace boost? We currently use range-v3 which for example has a zip function. In Faunus, extended particle properties are dynamically allocated at run-time, but the (segregated) memory handling is pretty naive and I'll keep investigating a switch to Aboria. Best, Mikael

[martinjrobins]

Hi Mikael. Yes, I think a meta-programming library like Brigand or Metal could replace the dependency on boost. Its something I'd like to do, once I have the time!