[gmx-developers] libgromacs vs libgromacs_core?

[Szilárd Páll]

On Sat, Sep 28, 2013 at 6:55 PM, Mark Abraham <mark.j.abraham at gmail.com> wrote:
> On Sat, Sep 28, 2013 at 5:56 PM, Szilárd Páll <szilard.pall at cbr.su.se> wrote:
>> Hi,
>>
>> 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.
>
> What external dependencies do we have that are optional for mdrun and
> cannot be turned off at CMake level?

I'm not familiar with the current dependencies of 5.0 code to a great
detail, but actually I have mis-phrased the problem statement.

It is not just a matter of what _libraies_ does mdrun depend on _now_,
but in general, what will go into libgromacs that could potentially
set back porting mdrun to a new platform in (almost) as little time as
in the days of C99 code <v5.0 code. This includes external library
dependencies as well as language features and constructs which may
prevent porting or efficient use on some hardware.

Additionally, one can also look at the issue the other way around:
while maintaining the portability of mdrun should be a major goal,
having to keep this restriction in mind when writing tools code is
both a burden as well as a risk - it takes a C++/HPC expert to know
what language features of say C++11 are "too much" for non-mainstream
compilers (and we have a trend of squeezing in more and more allowed
stuff). Hence, IMO it would be advantageous to not have to scrutinize
every bit of code for a high level of portability that goes into
libgromacs because, I think, that's the sure way to make the situation
disadvantageous for both mdrun and tools.

While it may seem that I'm putting too much emphasis on this, I know
concrete examples of projects which took a disproportionate amount of
time to get running on some platform simply because of dependencies or
the use of C++ and its features.

Cheers,
--
Szilárd

>
> Mark
> --
> 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.