[gmx-developers] libgromacs vs libgromacs_core?

[Szilárd Páll]

On Sat, Sep 28, 2013 at 7:32 PM, David van der Spoel
<spoel at xray.bmc.uu.se> wrote:
> 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?

Not really - at least not in the current setup. We do not and probably
will not include in our builds compilers like pgi, pathscale, xlc,
Fujitsu C compiler, and other embedded compilers. It's not entirely
trivial to predict what the future is e.g. if Tilera come up with a
promising HPC platform or the IBM + NVIDIA (ref: Open Power) marriage
results in a new fancy machine (which are not out of the question, not
even in the 12 months time-frame), it may take quite some effort to
strip away the portability bottlenecks just to compile mdrun on such a
machine, let alone start optimizing for it.

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