[gmx-developers] DCD / Licence

Roland Schulz roland at utk.edu
Fri Jul 3 22:06:49 CEST 2009


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?

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?


> i'd suggest you start from the latest (cvs) code, as VMD-1.8.7 is about
> to be released very, very soon and that would require vmdplugin.h,
> molfile_plugin.h and vmdconio.h.
>
> there have been some significant improvements. for example, the improved
> plugin API has support for reading angle, dihedral, improper
> definitions, or velocities (for file formats that support it).


Thanks

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

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


More information about the gromacs.org_gmx-developers mailing list