[gmx-developers] libgromacs vs libgromacs_core?

[Mark Abraham]

On Sat, Sep 28, 2013 at 7:17 PM, Szilárd Páll <szilard.pall at cbr.su.se> wrote:
> 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.

This has been discussed at great length over years on this list and on
Redmine. The summary material on the web is a pretty accurate state of
affairs: we require C++98; stuff in POSIX is probably fine, but be
aware there are non-POSIX platforms. For example, we want smarter
pointers than C++98, and so we bundle a few pieces of Boost that make
that possible, unless the compiler in use offers C++11 support.

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

This, too, has been discussed a lot. There's a list of allowed C++
constructs on the website.

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

Right, so we are being very conservative. If we are ever able to
separate modules such that we can relax that requirement (e.g. for
ease of writing tools code) then we can consider doing that. But for a
non-trivial period of time, the question of whether a compiler can do
what parts of C++11 efficiently or portably is moot. The first
fully-compliant C++11 compilers are fresh on the market, and GROMACS
is pretty unmodular.

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

Sure. We are trying to learn from those lessons. What do you think we
need to do more?

Mark