[gmx-developers] libgromacs vs libgromacs_core?

[David van der Spoel]

On 2013-09-28 19:17, Szilárd Páll 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.
>
> 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.

This is an important point, but doesn't Jenkins help by compiling with 
older compilers as well as state of the art?

I agree we should be careful with how much C++ tricks we use.

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


-- 
David van der Spoel, Ph.D., Professor of Biology
Dept. of Cell & Molec. Biol., Uppsala University.
Box 596, 75124 Uppsala, Sweden. Phone:	+46184714205.
spoel at xray.bmc.uu.se    http://folding.bmc.uu.se