Is your feature request related to a problem? Please describe.
qcio provides structured fields for things like method, basis, calctype, and structure inputs like symbols, geometry, charge, and multiplicity.
All encoders need to do some verification that these values aren't incorrectly set inside of .keywords directly, leading to duplicate values and a possibly mistaken encoding of the ProgramInput into a program-native file format.
Create a generalized validation checker that builds on the examples in encoders/terachem.py and encoders/orca.py.
Describe the solution you'd like
I think the checker could take something like this that maps the location of the invalid input to the correct location on the qcio object:
_INVALID_INPUTS = {
"runtype": "calctype", # example for TeraChem or any top-level keyword
"method.method": "model.method", # Example of nested keyword inside the method dict block (e.g., ORCA's blocks)
}
Then the validator could operate much like the ORCA _validate_keywords function and it just consumes the _INVALID_INPUTS dictionary and the keywords object and then performs the validation generically. This could possibly even be simplified further by thinking about the _INVALID_INPUTS dictionary in reverse since all encoders will need to specify the invalid, native-file location for the qcio structured values. This could give each encoder a simple template for the values they need to fill in and then the validator operates on a keywords dict and that objects, e.g.,:
class QCIOKeywordsValidation(...):
calctype: str # example: "runtype" or "method.runtype"
basis: str # example: "basis" or "basis.basis"
Describe alternatives you've considered
Per encoder validation logic that has to be re-thought everytime. Multiple definitions in each file of where "calctype" lives in qcio, which feels redundant.
Is your feature request related to a problem? Please describe.
qcioprovides structured fields for things likemethod,basis,calctype, and structure inputs likesymbols,geometry,charge, andmultiplicity.All encoders need to do some verification that these values aren't incorrectly set inside of
.keywordsdirectly, leading to duplicate values and a possibly mistaken encoding of theProgramInputinto a program-native file format.Create a generalized validation checker that builds on the examples in
encoders/terachem.pyandencoders/orca.py.Describe the solution you'd like
I think the checker could take something like this that maps the location of the invalid input to the correct location on the
qcioobject:Then the validator could operate much like the ORCA
_validate_keywordsfunction and it just consumes the_INVALID_INPUTSdictionary and the keywords object and then performs the validation generically. This could possibly even be simplified further by thinking about the_INVALID_INPUTSdictionary in reverse since all encoders will need to specify the invalid, native-file location for theqciostructured values. This could give each encoder a simple template for the values they need to fill in and then the validator operates on a keywords dict and that objects, e.g.,:Describe alternatives you've considered
Per encoder validation logic that has to be re-thought everytime. Multiple definitions in each file of where "calctype" lives in
qcio, which feels redundant.