[gmx-developers] libxml2 versus JSON

[Teemu Murtola]

Hi,

just a few quick comments on the overall scheme of things for now.

On Mon, May 23, 2016 at 5:13 PM Mark Abraham <mark.j.abraham at gmail.com>
wrote:

> Modules of mdrun (whether standard or via some kind of extension, which
> was a frequent need for people at the Gottingen workshop) should be able to
> declare their own mdp-style settings without modifying half a dozen files
> needed to also support gmx check and dump along with the obvious grompp and
> mdrun. A reasonably elegant way for them to do that is to register a schema
> fragment, so grompp can do syntax checking.
>

Note that if it really is a JSON schema fragment, as a string, that will
couple every single module to the input format being JSON, instead of
abstracting the format to a single place.


> mdrun modules can do their own initialization by calling routines that
> query the validated input string, filling their own structs as necessary
> for convenience or perhaps performance. We have been moving towards use of
> inputrec that is const very early in mdrun, but moving to JSON gives us an
> opening to do this formally and avoid the e.g. pressure-coupling module
> being able to read parameters from the temperature-coupling module without
> the developer being forced to consider that design issue up front.
>

Just making the validated input string queryable for all seems to achieve
the exact opposite: it makes a single, global instance of the whole
configuration that everyone can read and parse as they see fit, which makes
it possible for people to (mis)use data from other modules and even parse
it differently in different places in the code. And the input string has
even less compile-time checking or structure than the current t_inputrec.

To achieve proper isolation, we would need a pattern where the module can
declare their mdp options, and then it gets access to exactly those values.
Preferably without knowing anything about the underlying storage format
being JSON or having to declare the options in more than one place.
Everything else would need to be passed through explicit coding. One option
would be to use the options/ module for declaring the options, but that
would require some work to support structured data (in particular, arrays
of JSON objects would need some non-trivial work). This has the
disadvantage that it will be difficult to have the mdp file have structure
that does not closely reflect the structure of the code, but for most
cases, mdp options provided by different modules would probably fit within
their own dedicated sections... And it will be strict in enforcing that
isolation, for better or worse.

For reading data for analysis, or for pdb2gmx, the requirements are
probably different, as the module(s) that read the data can have that as
their main responsibility. So there it should be fine to just write classes
to extract certain things from the parsed data and expose that as useful
data structures (probably in a format where you can query it by
atom/residue/whatever name).

Best regards,
Teemu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20160525/7ca77898/attachment.html>