libAtoms / QUIP

libAtoms/QUIP molecular dynamics framework: https://libatoms.github.io
347 stars 122 forks source link

No documentation for xml parameter file format(s) #50

Closed max-veit closed 7 years ago

max-veit commented 7 years ago

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 commented 7 years ago

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 (notifications@github.com(mailto:notifications@github.com)) 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(https://github.com/libAtoms/QUIP/issues/50), or mute the thread(https://github.com/notifications/unsubscribe-auth/AFAG50-mhv_4rDbELtNi_GiAYU6nvPFzks5rcce6gaJpZM4MAnDl).

max-veit commented 7 years ago

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 commented 7 years ago

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 (notifications@github.com) 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: https://github.com/libAtoms/QUIP/issues/50#issuecomment-280066520

max-veit commented 7 years ago

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.