[gmx-developers] DCD / Licence
Axel Kohlmeyer
akohlmey at cmm.chem.upenn.edu
Fri Jul 3 22:42:32 CEST 2009
On Fri, 2009-07-03 at 16:06 -0400, Roland Schulz wrote:
>
>
> On Fri, Jul 3, 2009 at 1:12 PM, Axel Kohlmeyer
> <akohlmey at cmm.chem.upenn.edu> wrote:
> On Fri, 2009-07-03 at 12:58 -0400, Roland Schulz wrote:
>
>
>
> > Using the VMD plugin API would add 3 addiotional source
> files (hash.c,
> > molfile_plugin.h, vmdplugin.h).
>
> > Does this matter? Should I do this so that we can easily add
> further
> > vmd supported types in the future?
>
>
> if you use the molfile API, you automatically add _all_
> formats
> that the molfile plugins support. that would include for
> example
> native formats of LAMMPS, desmond, amber, amber/netcdf on top
> of .dcd without any extra coding effort from you.
>
> I'm not opposed to it. I just don't know what everyone things about
> adding so much additional source.
>
> 1) a few additional source files for the API
> 2) the source for the different formats
>
> which file formats should be included in the gromacs code? Which
> should be compiled in by default?
i would not include the whole code, just the molfile API interface
and then dlopen() the individual plugins. so one can use, e.g. an
existing VMD installation (provided the API matches).
> Or do we want to allow GROMACS to be compiled agains the vmd plugin?
> Then one would compile the vmd plugin directory and then could
> configure with : configure --with-vmd=$VMD_PATH
>
> So I see 4 alternatives:
> - Just add DCD (because it is most often used?)
> - Add API and DCD and very few common used formats (which?)
> - Add this "--with-vmd" option
> - Add the whole vmd plugin code to GROMACS
> i'm not sure why you'd need hash.c. for writing an interface
> to
> the plugin API you should only need files from the include
> directory.
>
> I looked at the catdcd as an example. One needs to somehow have the
> register of the file formats. How do you do that register without
> hash? Is there a good example of the usage besides catdcd?
a simple list will do. you don't have to go through the list
very often. of course a hash is more convenient.
for static linkage, some macros are provided to make it easier
to interface. see the the attached code i wrote a while ago to
interface the mofile read API to fortran. for dynamic linkage
and plugin management, i suggest you look at the PluginMgr.C
source from VMD. it references also vmddlopen.c as a portable
wrapper for dlopen.c. BTW, the VMD license allows you to use
up to 10% of the code for other purposes... ;-)
> the main advantage is that you don't have to maintain the .dcd
> (or others format) readers yourself and keep it in sync with
> the VMD/molfile code base. there is already too much code
> replication already. for VMD i'm planning to adjust the
> gromacs
> support to use libxdrfile from the gromacs distribution, for
> example.
>
> I kept the changes very few (basically just removing the plugin api).
> But of course your solution is much better if one wants more than just
> DCD.
i'm mainly concerned about maintainability and project fragmentation.
you have a valid point in supporting only DCD and having a simple
interface. if your changes could be implemented with a couple of
well crafted #ifdefs, it would still be possible to have the source
in the VMD plugin cvs to be _the_ authoritative source. i.e. if somebody
in gromacs fixes a bug, it can be easily integrated back into VMD
and vice versa.
one of the big weaknesses of the MD community compared to,
say, astrophysics, is the fragmentation of project and lack
of interoperability in file formats and data management.
my hope is that popular projects like VMD, gromacs, NAMD, pymol
(which also supports molfile, btw) and others start to converge
to be ready for future challenges like handling multi-million
atom simulations, efficient lossless and lossy compression,
mult-resolution data storage, efficient parallel and out-of-core
data access. too much is currently done with ad-hoc solutions,
but supporting mutual APIs will allow to mutually benefit from
improvements.
cheers,
axel.
p.s.: sorry if i'm getting too political at the end. this is
something that i'm very passionate about. just disregard it,
if you think i'm going too far. ;-)
>
> Roland
>
>
>
> cheers,
> axel.
>
>
>
> > Roland
> >
> > On Fri, Jul 3, 2009 at 11:59 AM, Axel Kohlmeyer
> > <akohlmey at cmm.chem.upenn.edu> wrote:
> > roland,
> >
> > On Fri, Jul 3, 2009 at 6:44 AM, Roland
> Schulz<roland at utk.edu>
> > wrote:
> > > Hi,
> > >
> > > what do you think about adding DCD read support to
> the
> > tools? Quite a few
> > > people in our group use the tools but (for a
> number of
> > reasons) do the
> > > simulation still with other MD packages. It is
> inconvenient
> > to have to
> > > convert the trajectories.
> >
> >
> > instead of adopting code to only read .dcd files,
> > why don't you write an interface to the VMD molfile
> API?
> > should be even less work and then you would
> interface
> > gromacs to a large number of file formats. also it
> would
> > avoid replicating and code (and problems with
> diverging
> > developments and missing bugfixes) and also you can
> add
> > new file formats or updated readers/writers
> > on the fly through the dynamic loading of plugins.
> >
> > cheers,
> > axel.
> >
> > p.s.: we're also in the process of gradually
> revising the
> > molfile API to make it more flexible and powerful
> and
> > particularly add support for "out-of-core"
> processing of
> > a collection of files (primarily for VMD but not
> limited to
> > it).
> > that might be interesting for gromacs tools just as
> well.
> >
> >
> > >
> > > Is it OK to add code which is under the University
> of
> > Illinois Open Source
> > > License? It is GPL compatible so does not cause
> license
> > conflicts
> > >
> >
> (http://en.wikipedia.org/wiki/University_of_Illinois/NCSA_Open_Source_License).
> > >
> > > Roland
> > >
> > > --
> > > ORNL/UT Center for Molecular Biophysics
> cmb.ornl.gov
> > > 865-241-1537, ORNL PO BOX 2008 MS6309
> > >
> >
> > > _______________________________________________
> > > 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.
> > >
> >
> >
> >
> > --
> >
> >
> =======================================================================
> > Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu
> > http://www.cmm.upenn.edu
> > Center for Molecular Modeling -- University of
> > Pennsylvania
> > Department of Chemistry, 231 S.34th Street,
> Philadelphia, PA
> > 19104-6323
> > tel: 1-215-898-1582, fax: 1-215-573-6233,
> office-tel:
> > 1-215-898-5425
> >
> =======================================================================
> > If you make something idiot-proof, the universe
> creates a
> > better idiot.
> >
> > _______________________________________________
> > 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.
> >
> >
> >
> >
> > --
> > ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
> > 865-241-1537, ORNL PO BOX 2008 MS6309
> > _______________________________________________
> > 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.
>
> --
> =======================================================================
> Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu
> http://www.cmm.upenn.edu
> Center for Molecular Modeling -- University of
> Pennsylvania
> Department of Chemistry, 231 S.34th Street, Philadelphia, PA
> 19104-6323
> tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel:
> 1-215-898-5425
> =======================================================================
> If you make something idiot-proof, the universe creates a
> better idiot.
>
> _______________________________________________
> 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.
>
>
>
>
> --
> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
> 865-241-1537, ORNL PO BOX 2008 MS6309
> _______________________________________________
> 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.
--
=======================================================================
Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu
Center for Molecular Modeling -- University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: f77-molfile.tar.gz
Type: application/x-compressed-tar
Size: 5544 bytes
Desc: not available
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20090703/8d1711b4/attachment.bin>
More information about the gromacs.org_gmx-developers
mailing list