[gmx-developers] DCD / Licence
Erik Lindahl
lindahl at cbr.su.se
Sat Jul 4 13:56:27 CEST 2009
Hi,
Having optional support for a dlopen API sounds great. You probably
don't want to make it default, since that could screw up compilation
on many platforms.
Our only hard requirements are:
1) We need to be able to distribute the code as GPL/LGPL (instead of a
combination of licenses). The 10% clause probably doesn't fly with
this, since the one could imagine 10 different people copy 10% each,
distribute as GPL, then somebody else (who gets it under strict GPL,
where there cannot be side clauses) merges it and has the original
code under GPL.
2) The basic code must be possible to compile without any extra
libraries. Optional stuff can use them, though!
Cheers,
Erik
On Jul 4, 2009, at 1:23 PM, Roland Schulz wrote:
>
>
> On Fri, Jul 3, 2009 at 4:42 PM, Axel Kohlmeyer <akohlmey at cmm.chem.upenn.edu
> > wrote:
> 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:
>
>
> 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).
>
> Erik, David, Berk: What do you think about that? Do you like that
> idea?
>
> If so: At what stage do we want to configure the path to the molfile
> plugin folder?
> We could:
> - add to configure a --with-vmd option
> - that would set a variable (e.g. GMX_VMD) in GMXRC
> - trxio would read GMX_VMD and if it finds the plugins allow also
> reading of the molfile formats
> - if it does not find the plugin (or GMX_VMD is not set) and one
> tries to read e.g. a dcd it would give an error
>
> In a first stage only trajectory formats would be supported. Of
> course later one could also support structure format, so that
> charges could be read for e.g. g_diplole.
>
> Do we want to support only dynamic linking (dlopen) for the vmd
> plugins or as an alternative also static?
>
> 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... ;-)
>
> Thanks for pointing that out. Does for less than 10% count the
> Illinois Open Source License?
> Or where do I find out the requirements to add license/copyright
> information to the file/package under that 10% clause?
>
> > 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.
>
> I think I could do it with a few #ifdefs if we don't want to go the
> molfile path.
>
> 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.
>
> Yes I agree. That is very suboptimal.
>
> 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.
>
> It would be great but would need very well designed APIs. E.g.
> molfile is not ready for the future as it does not support parallel
> IO (just as one example). So a constant update of the APIs is
> required and of course the APIs should be decided by the community
> and not just by one group.
>
> 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. ;-)
>
> No I think this is very interesting. Is there some mailinglist /
> forum where this would be more on-topic?
> I would be interested in follow up on this.
>
> Roland
>
>
>
> >
> > 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.
>
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20090704/ff1a0739/attachment.html>
More information about the gromacs.org_gmx-developers
mailing list