[gmx-developers] libgromacs vs libgromacs_core?

[Szilárd Páll]

On Sat, Sep 28, 2013 at 8:05 PM, Teemu Murtola <teemu.murtola at iki.fi> wrote:
> Hi,
>
> On Sat, Sep 28, 2013 at 6:56 PM, Szilárd Páll <szilard.pall at cbr.su.se>
> wrote:
>>
>> I would like to bring up the topic of keeping mdrun lean and as
>> dependency-free as possible (for HPC/exotic platforms).
>>
>> This has been discussed earlier, but I'm not sure what the decision
>> was (AFAIK there wasn't any) and what the current direction is. The
>> two possibilities discussed:
>> - splitting libgromacs into libgromacs and libgromacs_core (where
>> mdrun depends only on the latter which is as portable and lightweight
>> as possible);
>> - more of a workaround solution: allowing to build a stripped-down
>> version of libgromacs that mdrun links against; this libgromacs may
>> still be better called libgromacs_core to allow conflict-free
>> installation of e.g. full non-MPI build + reduced MPI-enabled mdrun
>> build in the same location.
>
>
> Just as a remark, the second option is already implemented (very roughly) in
> https://gerrit.gromacs.org/#/c/2571/. I have nothing against a more

Seeing that commit reminded me of this topic. :)

> elaborate solution, but that requires some concreteness to what would the
> concrete restrictions be, how to deal with utility code used by both mdrun
> and tools, and how to actually do the split (technically won't be a problem,
> but more on the logic level: do we, e.g., want/allow to sacrifice some
> features of the "full" mdrun in the "reduced" version). The last time this

Indeed, and I was hoping that such concrete aspects of a split will be
brought up in this discussion - instead of claims of this being a
non-issue (at least not a timely one).

Having spent only a couple of minutes thinking about what could be
obviously moved out of a potential libgromacs_core, here are a couple
of things:
- use of exceptions: I was going to say that we could make
libgromacs_core exception-free, but that's probably not going to be a
popular suggestions; however, outside of libgromacs_core exceptions
could possibly be used in a more liberal manner.
- fancy containers vs flat arrays for generic storage (e.g coordinates, forces).
- cache-friendly and concurrent data-structures (required in core
probably not in tools).
- AoS vs SoA.

I know these suggestions are rather vague, so I think here's the point
where a  bit of brainstorming could help.



> was discussed, I think I wrote a long e-mail (or perhaps a comment in
> Redmine, can't remember) to enumerate some points that need to be
> considered, with the result that the discussion died immediately... I can
> try to look that up if people are really interested.

Please do. I have probably not commented much (if at all) - sorry about that.

>
> Best regards,
> Teemu
>
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.