[gmx-developers] future of installed headers and libraries

[Mark Abraham]

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

 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20140707/f912ba17/attachment.html>