[gmx-developers] future of installed headers and libraries

[Christoph Junghans]

2014-07-07 1:35 GMT-06:00 Mark Abraham <mark.j.abraham at gmail.com>:
>
>
>
> On Mon, Jul 7, 2014 at 8:34 AM, Roland Schulz <roland at utk.edu> wrote:
>>
>>
>>
>>
>> On Mon, Jul 7, 2014 at 1:48 AM, Mark Abraham <mark.j.abraham at gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> For some time, GROMACS has installed a collection of its headers and
>>> libraries in the hope that they might be useful to third parties. I'm not
>>> aware of anybody actually doing so - please speak up if you know of any! All
>>> the derivative work of which I'm aware is either a fork of the code, or a
>>> wrapper over an executable.
Please don't! For me, it is ok to break the API with every major
release, but at least keep it public (install headers)

>>
>> https://github.com/rolandschulz/2pt/tree/master/grompy (only library not
>> header - not an approach I would do again, the latest version
>> (https://github.com/GromPy/GromPy) uses a modified version to insert hooks
>> into mdrun)
>
>
> OK, thanks. grompy seems like it would like it to be easy to write analysis
> tools. GromPy bundles patches to 4.0.7 that it seems to build itself, rather
> than using an installed version (even if modified). It does make more
> sophisticated use of GROMACS function calls than I was expecting to see! :-)
> I would suggest that a comprehensible do_md would make a more suitable
> vehicle for someone to implement GCMC.
>
>> http://www.votca.org/
>
>
> Its manual refers only to grompp and mdrun, along with another host of MD
> packages, so I'm not yet sure it is a client of installed headers and
> libraries. Christoph's past contributions to GROMACS make it seem like it
> should be, though!
VOTCA links against libgmx/libgromacs. (and uses binaries at run-time).
Like I said above, keep the API public please! VOTCA already has a
couple of ifdefs to support different gromacs versions/APIs (so far
4.0,4.5=4.6,5.0):
<https://code.google.com/p/votca/source/browse/?repo=csg#hg%2Fsrc%2Flibcsg%2Fmodules%2Fio>
So as long as the API stays stable within one release (X.Y.*) we can
adapt the VOTCA code to every new release.

Another code

MDSCTK:
https://github.com/douradopalmares/mdsctk


Christoph
>
>>> We already have some of our I/O functionality available as separate
>>> libraries. If we make our custom analysis functionality available, I'd much
>>> rather do that as a Python extension, or as a contribution to a dedicated
>>> MD-analysis project. mdrun... might never achieve a better "API" than
>>> grompp.
>>
>>
>> I think a Python API for the analysis library would be great. But I think
>> the way we should do it, is wrap the API we have. Thus I don't think a
>> Python extension is a reason against a C/C++ API but a reason for it.
>
>
> Sure, but the "API" we have seems like it is just a collection of everything
> that existed at some point. I'm not against having a public, stable API, but
> I am against preserving the existing "API" if it delivers little value
> internally or externally, and is an impediment to building software that
> might later be able to get an API worth having.
>
>>
>> Another huge advantage of a public API is that it helps to learn how
>> modules work. For the analysis modules where Teemu did that one only needs
>> to look a the user docu to understand how to use it.
>
>
> Yes, but having documentation for our modules (whether intended for
> third-party use or not) is distinct from requiring that we install lots of
> headers and worry about the ability and stability of code calling it.
> Whatever code we write will have its source available and can be used by
> someone, and it should be documented, and that code has an API (from a
> certain point of view). Those projects above that are using that internal
> API are going to get broken by our changes just like code depending on the
> stuff we currently install - which is why I see little value in installing
> it, or making a public/internal header distinction. This might change in the
> future.
>
> Cheers,
>
> Mark
>
>> Roland
>>
>> --
>> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
>> 865-241-1537, ORNL PO BOX 2008 MS6309
>>
>> --
>> Gromacs Developers mailing list
>>
>> * Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
>> posting!
>>
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>> * For (un)subscribe requests visit
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or
>> send a mail to gmx-developers-request at gromacs.org.
>
>
>
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or
> send a mail to gmx-developers-request at gromacs.org.



-- 
Christoph Junghans
Web: http://www.compphys.de