[gmx-developers] libxml2 versus JSON

Erik Lindahl erik.lindahl at gmail.com
Wed May 25 17:13:42 CEST 2016


> On 25 May 2016, at 16:40, David van der Spoel <spoel at xray.bmc.uu.se> wrote:
> You are absolutely right that my "approach" does not give us more than independence from the underlying library. However my concern has been for a while that waiting for one monster file format does not get us further either. Fitting force field files, topologies and lots of random data all in one structure is not the way forward either.
> But rather than whining I will propose a JSON schema for the WAXS patch that is in gerrit, then we can take the discussion from there.

A couple of things we could probably decide on relatively easy (and these are probably all needed for the WAXS stuff):

1) What grouping/nomenclature should we use for all stuff like this (physical data) on the very highest level?  

2) How should we handle/classify (nota bene: not implement) different scattering factors? They should likely go into separate objects, but somebody should likely spend a little time making a list of the ones we expect to implement, and then we can have a quick discussion in redmine that it makes sense.

3) How do we handle the mapping of particles (in particular for different force fields) to physical properties? I would guess that we might want to use elements when we can (to make things FF independent), but we also need ways to create arbitrary mappings, including wildcards. How do we handle cases with multiple alternative names for a residue? Some setups might use residue-like groups, but not all of them. 

4) How will we handle units and possibly conversions?

5) How do we handle literature references?



PS: As both Teemu & I commented about year ago, the old WAXS patch in gerrit suffers from a very large number concepts in a single change. I added some ~120 comments a year ago that I think nobody got back about. I can kind of understand that given the complexity, but given the patch’s age and that we now are all C++, I would strongly recommend trying to break it up into smaller parts rather than extending it!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20160525/f2609684/attachment.html>

More information about the gromacs.org_gmx-developers mailing list