You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@dgasmith
I'm not making separate issues for every point below because these are just a bunch of small suggestions that occurred to me when going through the spec.
Could we just mention on top that atomic units are used throughout? That clarifies some points, e.g. Hartree cannot be the right unit for a frequency.
results would be a clearer name than variables.
It is good to have some room for non-standardized results and options. However, just to make this json schema more useful, we'd rather standardize as much as possible, e.g. as follows:
Only allow standard keys in the results/variables dictionary. Anything non-standard would better go to a other_results dictionary, such that there are no name collisions later on.
Similarly for options used to specify the input: standardize anything that sits in options, while non-standard keys could be put in other_options.
There seems to be little reason for a separate return_value. It could be included in results/variables.
The text was updated successfully, but these errors were encountered:
@dgasmith
I'm not making separate issues for every point below because these are just a bunch of small suggestions that occurred to me when going through the spec.
results
would be a clearer name thanvariables
.results
/variables
dictionary. Anything non-standard would better go to aother_results
dictionary, such that there are no name collisions later on.options
used to specify the input: standardize anything that sits inoptions
, while non-standard keys could be put inother_options
.return_value
. It could be included inresults
/variables
.The text was updated successfully, but these errors were encountered: