program options beyond flat plain-old-data about qcengine HOT 14 OPEN

How restrictive would this be for something like Molpro or Psi4? Would allowing the user to write custom inputs (handled through something like Jinja) go against the QCArchive framework?

from qcengine.

I think jinja goes against QCA guarantees but not against QCA allowed entry points. So use at your own risk b/c not all input info is available for interpreting output.

This actually has to be the case b/c not all inputs fit in qcschema -- for example any multistage input violates the single driver field of qcschema.

What I personally would like to see is that no job that should be expressable in a single qcschema (like mp2c) needs jinja. But I acknowledge that it can be a step along the way for things that are easier to parse than express in an input.

from qcengine.

That sounds reasonable to me. For my projects (including my MolSSI Seed project) I'll probably need the ability to express a complicated input file, but then parse fairly standard items (energy and forces) from the output file.

from qcengine.

Right, I think the idea is compute is and always will be pure schema. However, if you want to alter the steps of the object you should be allowed to. We have the following layers for every executor:

• build_input - Takes in Schema and perhaps other data to form an input file.
• execute - Takes in a command line and a dictionary of filename : file content pairs, returns the content of all generated files.
• parse_output - Takes in a dictionary of filename : file content pairs and return schema-like objects
• compute - Calls the other three sequentially

For @sjrl you case would likely call the execute and parse_output as those should be canonical values (knowing that fields in the result might be slightly wonky).

Allowing this to go through the full QCArchive framework (including Fractal) would take some thinking. Discussing this in other areas what we would propose is something like the following (using embedding as a target):

• Build a custom executor and call it something like molpro-embedded that has an expanded input syntax. This executor would subclass the current Molpro executor and modify the build_input command.
• Register this with Engine (we need to add some hooks)
• Submit tasks through Fractal with the extended input framework and submit these to the molpro-embedded program.

from qcengine.

No real preference on the dunder keywords vs nested dictionaries. Curious if anyone else has thoughts here.

from qcengine.

from nwchem QA/tests

(a)  grid fine
(b)  grid lebedev H 350 18 I 350 18
(c)  grid ssf euler lebedev 75 11

from nwchem docs

 GRID [(xcoarse||coarse||medium||fine||xfine) default medium] \
      [(gausleg||lebedev ) default lebedev ] \
      [(becke||erf1||erf2||ssf) default erf1] \
      [(euler||mura||treutler) default mura] \
      [rm <real rm default 2.0>] \
      [nodisk]

three schematizing principles

1. The keywords section shall be approximately Dict[str, Union[bool, str, int, float, List, Tuple, Dict[str, Any]]]. Any module hierarchy shall be represented
   by double underscore. Any qcprogram direction is by prefixing the program
   with an underscore (or 2), so gamess_contrl__scftyp='rhf'

2. Keywords should be independent and granular such that they're approximately 1:1 with
   other programs, not 5:1. That is, no single method option should cover convergence, algorithm, and target roots all wrapped together. Also, separate, yet mutually exclusive, options sets are a last resort (e.g., three independent boolean options for rhf/uhf/rohf).

3. A user familiar with native QC program input deck and the schematizing
   principles should be able to readily write out the qcschema keywords section (say, 95% of the time) without consulting a glossary.

finally, the question

The one-word case (a) is simple: nwchem__dft__grid = 'fine'. The (b) case also representable at nwchem__dft__grid__lebedev = {'H': (350, 18), 'I': (350, 18)}. This already works in the formatter. Case (c) is the troublemaker.

• The repr most consistent with principle 3 would be nwchem__dft__grid = ['ssf', 'euler', {'lebedev': (75, 11)}] but this violates principles 1 and 2.
• The repr most consistent with principle 2 would be the below but this invents "partition" and "radial_quadrature", thereby violating principle 3.

nwchem__dft__grid__partition = 'ssf'
nwchem__dft__grid__radial_quadrature = 'euler'
nwchem__dft__grid__lebedev = (75, 11)  # or {'': (75, 11)}

• The compromises I can think of are:
  • the tuple (understandable w/o consulting nwc manual?)

nwchem__dft__grid = ('ssf', 'euler')  # = 'ssf' would also work if only one needed
nwchem__dft__grid__lebedev = (75, 11)

• the booleans (discouraged in principle 2)

nwchem__dft__grid__ssf = True
nwchem__dft__grid__euler = True
nwchem__dft__grid__lebedev = (75, 11)

• the schism. throwing out principles 1 & 2 and optimizing for the user with principle 3 since QCSchema.keywords can hold it. this will break the 1:1 between qcng and qcdb representations.

Personally, I'd like to avoid the schism since I think crafting the qcschema keywords repr with the three principles in mind hits a lot of use cases. But I'm glad to hear other thoughts. Especially with Molpro lurking. :-)

P.S. In all this, ignore the formatting of the repr back to an input file. That tends to be straightforward and general. In this post, only concerned with the user representation of instructions to the qcprog through schema.

@vivacebelles

from qcengine.

@mattwelborn @sjrl Good to get comments from you as well I think.

from qcengine.

How would this proposal interact with nested commands found in entos? e.g.

dft(
  structure( molecule = methanol )
  xc = PBE
  ao = 'Def2-SVP'
  df = 'Def2-SVP-JFIT'
)

versus

optimize(
  structure( molecule = methanol )
  dft(
    xc = PBE
    ao = 'Def2-SVP'
    df = 'Def2-SVP-JFIT'
  )
)

from qcengine.

Thinking about the first compromise, it may break principle 3 since there are options that would be nested while others are allowed to be listed together, i.e. nwchem_dft__grid__lebedev vs nwchem_dft__grid as it may not be intuitive how that split happens for native users.

The booleans appeal to me, but that's also probably due to familiarity in some of the options we've been working on in qcdb.

from qcengine.

@mattwelborn, I think since qcschema is single-calc focused, there isn't the possibility of that dft(...) section appearing twice, once in an opt and once in a sp. right? In that case, both you mentioned are the below. Is PBE and object or str?

entos__dft__xc = PBE
entos__dft__ao = 'Def2-SVP'
entos__dft__df = 'Def2-SVP-JFIT'

from qcengine.

entos EMFT won't work with this strategy:

emft(
  structure( molecule = methanol )
  active = [1,2]
  dft(
    xc = PBE
    ao = 'Def2-SVP'
  )
  dft(
    xc = LDA
    ao = 'STO-3G'
  )
)

from qcengine.

See also the nightmare that is Molpro: #198

from qcengine.

Is the emft two calculations or one?

from qcengine.

It's one calculation with two coupled subsystems whose Fock builders are specified by the dft commands.

from qcengine.