Reading multi-part configurations across different back-ends

[jhenin]

A topic for discussion: in NAMD, multiple config files can be read using the scripting interface. The most interesting use case for me now is having one file with colvar definitions, written using the VMD dashboard, and one with biases.

For that to make sense, we'd need a system to read input from several files for each back-end. Any thoughts on that?

[jvermaas]

Just to play devil's advocate here, but wouldn't that use case be covered by just catting the two files together? cat file1.conf file2.conf > merged.conf is a pretty simple command to learn/use...

[jhenin]

@jvermaas point well taken. That is certainly a simple thing to do, under the right conditions. We do have users who might want to give their simulation a try on windows before moving to a production machine. That's also another file to keep track of - ideally you might want a Makefile to keep the consolidated config file up to date.

So the question is: do we want cat as part of the official user interface for Colvars? I'm still hoping to offer a smoother workflow. For Gromacs there seems to be a simple way. That doesn't seem to be supported by the LAMMPS interface yet, and I don't have a solution for that side yet.

An alternate, generic solution, is to add an "include" command as a global Colvars keyword.

[giacomofiorin]

In LAMMPS, a call to the scripting commands can be issued from Python, if this is compiled in. If it's not, then adding the relevant option to fix_modify seems to be the way to go. The first is quick to do only on the Python side, the second needs changing LAMMPS core files, so that's a bit longer. Either way, I'd rather sort out the units support if you are considering users copying input files from the VMD Dashboard.

You could give an include keyword a try. However, keep in mind that the parser (and its syntax checks) need to be updated accordingly. This is easy to do when you parse line by line, but not for brace-delimited blocks.

[jhenin]

In LAMMPS, a call to the scripting commands can be issued from Python, if this is compiled in. If it's not, then adding the relevant option to fix_modify seems to be the way to go. The first is quick to do only on the Python side, the second needs changing LAMMPS core files, so that's a bit longer.

The second option seems good to me at the UI level. How much work is involved to implement it is a different question.

Either way, I'd rather sort out the units support if you are considering users copying input files from the VMD Dashboard.

Agreed! I need to look into that.

You could give an include keyword a try. However, keep in mind that the parser (and its syntax checks) need to be updated accordingly. This is easy to do when you parse line by line, but not for brace-delimited blocks.

Yup, I can imagine some complications popping up there. One idea is that it might be necessary to provide include_before and include_after, depending on the order in which the two files need to be parsed. So, I'm not pushing to implement this urgently.

[akohlmey]

On Mon, Feb 11, 2019 at 1:05 PM Jérôme Hénin notifications@github.com wrote:

In LAMMPS, a call to the scripting commands can be issued from Python, if this is compiled in. If it's not, then adding the relevant option to fix_modify seems to be the way to go. The first is quick to do only on the Python side, the second needs changing LAMMPS core files, so that's a bit longer.

the fix_modify mechanism in LAMMPS is quite powerful (see the USER-ATC package) and seems to me the logical way to proceed. it could be used for a variety of purposes, e.g. to request a dump of the current configuration and/or a restart, or to trigger some analysis options and more. not very much effort to add. i can produce the changes needed in fix colvars easily.

include files are nasty, since you need to save the parser state and return, especially when people will want to try doing nested includes etc.

axel.

The second option seems good to me at the UI level. How much work is involved to implement it is a different question. Either way, I'd rather sort out the units support if you are considering users copying input files from the VMD Dashboard. Agreed! I need to look into that. You could give an include keyword a try. However, keep in mind that the parser (and its syntax checks) need to be updated accordingly. This is easy to do when you parse line by line, but not for brace-delimited blocks. Yup, I can imagine some complications popping up there. One idea is that it might be necessary to provide include_before and include_after, depending on the order in which the two files need to be parsed. So, I'm not pushing to implement this urgently.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Colvars/colvars/issues/215#issuecomment-462430941, or mute the thread https://github.com/notifications/unsubscribe-auth/AARp40lXde792626i_6rBya1bIvTCY_Wks5vMbDcgaJpZM4a0GiV .

-- Dr. Axel Kohlmeyer akohlmey@gmail.com http://goo.gl/1wk0 College of Science & Technology, Temple University, Philadelphia PA, USA International Centre for Theoretical Physics, Trieste. Italy.

[jhenin]

Thanks @akohlmey for your input, and thinly veiled offer to help!

[giacomofiorin]

@akohlmey Thanks for pointing out fix atc's case. I looked quickly, and didn't realize that the entirety of fix_modify commands are actually implemented in the sub-classes.

I suppose you'd much rather help with this than risk seeing an infinite recursion sneak into LAMMPS? :-)

[akohlmey]

On Mon, Feb 11, 2019 at 2:35 PM Giacomo Fiorin notifications@github.com wrote:

@akohlmey https://github.com/akohlmey Thanks for pointing out fix atc's case. I looked quickly, and didn't realize that the entirety of fix_modify commands are actually implemented in the sub-classes.

it is not the entirety, but only options, that are not handled by Fix::modify_params() (it is a bit convoluted, and the difference between the two APIs of just one letter is not making me happy, either). this is why Fix::modify_param() returns an int signifying the number of arguments consumed.

I suppose you'd much rather help with this than risk seeing an infinite recursion sneak into LAMMPS? :-)

e vero.

pull request with demo code is submitted

axel

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Colvars/colvars/issues/215#issuecomment-462463728, or mute the thread https://github.com/notifications/unsubscribe-auth/AARp42glYqhxRSCNP9btRvpSNcAhN4gwks5vMcYFgaJpZM4a0GiV .

-- Dr. Axel Kohlmeyer akohlmey@gmail.com http://goo.gl/1wk0 College of Science & Technology, Temple University, Philadelphia PA, USA International Centre for Theoretical Physics, Trieste. Italy.