<div dir="ltr">Hi,<div><br></div><div>just a few quick comments on the overall scheme of things for now.<br><br><div class="gmail_quote"><div dir="ltr">On Mon, May 23, 2016 at 5:13 PM Mark Abraham &lt;<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>&gt; wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>Best regards,</div><div>Teemu</div></div></div></div>