No documentation for xml parameter file format(s)

[max-veit]

It's incredibly frustrating as a new user of a potential to try to figure out what XML format will initialize it properly. For instance, with a FilePot, it currently seems impossible to specify a set of calc_args that will be used on every call, even though it seems there should be a straightforward way to do this in XML.

We need better documentation for how to go about setting up an XML parameter file for a potential in general, and some of the more complicated potentials specifically. The examples in share/Parameters are quite minimal and don't provide much useful info on how these things are actually parsed.

Normally I'd volunteer to write some of this documentation, but I still have no idea how the parsing for a general Potential xml stanza works.

[gabor1]

isn't there some confusion of terminology here? the contents of the xml is used to initialise the potential. calc_args is something that the quip command line uses and appends it to the argument string on every call. if you find that a potential parses options in its calc call that you would like to set at initialisations, you need to edit the source, create new variables in the potential type, and add the parsing and setting of them in the init routine. so i'm claiming that what you want is not actually calc_args. the reason there is no generic doc for xml is that every potential does its own parsing, and accepts different options.

…

-- Gábor

On 14 February 2017 at 16:26:50, Max Veit ***@***.******@***.***)) wrote: It's incredibly frustrating as a new user of a potential to try to figure out what XML format will initialize it properly. For instance, with a FilePot, it currently seems impossible to specify a set of calc_args that will be used on every call, even though it seems there should be a straightforward way to do this in XML. We need better documentation for how to go about setting up an XML parameter file for a potential in general, and some of the more complicated potentials specifically. The examples in share/Parameters(https://github.com/libAtoms/QUIP/tree/public/share/Parameters) are quite minimal and don't provide much useful info on how these things are actually parsed. Normally I'd volunteer to write some of this documentation, but I still have no idea how the parsing for a general Potential xml stanza works. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub(#50), or mute the thread(https://github.com/notifications/unsubscribe-auth/AFAG50-mhv_4rDbELtNi_GiAYU6nvPFzks5rcce6gaJpZM4MAnDl).

[max-veit]

isn't there some confusion of terminology here? the contents of the xml is used to initialise the potential. calc_args is something that the quip command line uses and appends it to the argument string on every call. if you find that a potential parses options in its calc call that you would like to set at initialisations, you need to edit the source, create new variables in the potential type, and add the parsing and setting of them in the init routine.

so i'm claiming that what you want is not actually calc_args.

Currently, there seems to be no other way to pass important command line arguments to a command called by FilePot. I suppose they could be included with the command itself, but drivers like castep_driver.py expect the arguments in a different order -- first xyzfile and outfile, then additional args -- which doesn't work with that approach.

So it looks like FilePot should be changed to accept a list of command line arguments that will always be added after xyzfile and outfile, since these (in cases like the template file) essentially define the potential. The calc_args can still be appended to the end as optional extras.

the reason there is no generic doc for xml is that every potential does its own parsing, and accepts different options.

Then maybe a good place to start would be to document how Potential (the base class) parses its XML stanza, what arguments it takes, and how this relates to the quippy or the command-line arguments for initializing the potential. This would then serve as a good introduction for figuring out how other potentials are initialized.

[gabor1]

Does the castep_driver take any other arguments? things like molpro, castep, vasp etc. take all their parameters from templates. But sure, if you feel it would be helpful to generalise FilePot to use extra args, I don't see anything wrong with that.  If you initialise a potential with init args "--help" it should list all its options, right? 

…

-- Gábor

On 15 February 2017 at 17:48:45, Max Veit ***@***.***) wrote: > isn't there some confusion of terminology here? the contents of the xml is used to initialise the potential. calc_args is something that the quip command line uses and appends it to the argument string on every call. if you find that a potential parses options in its calc call that you would like to set at initialisations, you need to edit the source, create new variables in the potential type, and add the parsing and setting of them in the init routine. > > so i'm claiming that what you want is not actually calc_args. Currently, there seems to be no other way to pass important command line arguments to a command called by FilePot. I suppose they could be included with the command itself, but drivers like `castep_driver.py` expect the arguments in a different order -- first `xyzfile` and `outfile`, then additional args -- which doesn't work with that approach. So it looks like FilePot should be changed to accept a list of command line arguments that will always be added after `xyzfile` and `outfile`, since these (in cases like the template file) essentially define the potential. The `calc_args` can still be appended to the end as optional extras. > the reason there is no generic doc for xml is that every potential does its own parsing, and accepts different options. Then maybe a good place to start would be to document how `Potential` (the base class) parses its XML stanza, what arguments it takes, and how this relates to the quippy or the command-line arguments for initializing the potential. This would then serve as a good introduction for figuring out how other potentials are initialized. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #50 (comment)

[max-veit]

The documentation for xml initialisation of the most common potentials should probably be merged with the introductory IPython tutorial or other introductory quip/quippy tutorials -- see #59.