-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
program options beyond flat plain-old-data #70
Comments
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? |
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 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. |
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. |
Right, I think the idea is
For @sjrl you case would likely call the 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):
|
No real preference on the dunder keywords vs nested dictionaries. Curious if anyone else has thoughts here. |
from nwchem QA/tests
from nwchem docs
three schematizing principles
finally, the questionThe one-word case (a) is simple:
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. |
@mattwelborn @sjrl Good to get comments from you as well I think. |
How would this proposal interact with nested commands found in entos? e.g.
versus
|
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. 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. |
@mattwelborn, I think since qcschema is single-calc focused, there isn't the possibility of that
|
entos EMFT won't work with this strategy:
|
See also the nightmare that is Molpro: #198 |
Is the emft two calculations or one? |
It's one calculation with two coupled subsystems whose Fock builders are specified by the dft commands. |
At some point QCEngine will have to confront what options look like in non psi4/cfour/qchem-like programs. For example,
is nwchem for boolean direct algorithm for dft. Another example is
ESTATE=0/1/0/0
for an array variable in Cfour. even if the user knew the option and value they wanted (respectively, dft direct on and B1 state only in C2v), the settings of the keywords block in qcschema would be very different depending on whether they knew python best (dft_direct = True
,estate=[0, 1, 0, 0]
) or the target program domain language best. naturally, the input file must be formattable from the qcschema keywords dict.My philosophy has been that the keyword RHS must be in natural python format (
True
,[0, 1, 0, 0]
) and the LHS must be predictable by someone who knows the program DSL (domain specific lang) with double underscore being any module separator, sodft__direct
andestate
. That way, we’re only transforming, not making a new DSL. Somehow, will have to work Molpro into this.This much, as I see it, is in the qcengine domain, not the qcdb (which is concerned with translating LHS options). Any concerns/disputes/that-doesn’t-belong-here-arguments before I act like this is qcng’s philosophy, too?
__
-separated vs. nested dict: I used to use the nested dict but find the__
separator much easier on the user. Since nested dict is an intermediate in:__
-sep-string --> nested-dict --> formatted-input, I can see allowing either at the qcng level.The text was updated successfully, but these errors were encountered: