Sebastian Husch Lee

> so what you are saying is that every function, including the component constructor where we currently pass `use_gpu` should have devices as an optional argument. Yes I think this...

> Yes, it seems to be already used everywhere, but we should make sure that it does get used in addition to making sure we provide devices parameter. Yes I...

This would be greatly helpful to me as well

> Directives are not ordered. (@sjrl please verify this last point). That is correct, directives of a given command are not ordered. As a side tangent directives can be placed...

I like this idea a lot! I only have a few questions and comments. First I think we can continue to handle `symmetry` and `memory` through the existing `AtomicInput` (handled...

> So keywords["directives"]: Optional[Set[Directive]]? Yup! So the only thing that this structure wouldn't support is the ability to set directives in between commands. In some complicated inputs (I believe @loriab...

I guess in my above example, we could just use the `commands` structure and do something like ``` "commands": [ {"name": "df-hf",}, { "name": "local", "kwargs": {"distp": 8, "maxit_lmp2": 1,...

Hmm I do wonder, how is this meant to interact with the driver call? If the driver is `gradient` does that mean `force` should still be added after all `commands`...

> Would this also work for hessians? I believe so, although I don't have much experience with hessian calculations in Molpro. > After looking at various programs (and especially GAMESS),...

I think the plan for the above use of the `commands` keyword is to completely replace the `model.method` when writing the input file. So a kind of replacement for current...