MolSSI
Shape specification for contributed values, mostly for use in views
Contributed values come in all (array) shapes and sizes, and we need a way to specify these shapes. The current approach is to define shapes for each driver, but this requires that we create new drivers for each new type of contributed values. It might be preferable to explicitly store shape information in the values_structure field, but we need a specification for this.
Some examples of what will need to be handled:
- scalars
- fixed-length vectors (
(N, 3)for gradients) - square matrices, like hessians
- arbitrary-sized matrices like orbitals
- maybe 4-tensors The size of molecules, basis sets, etc will vary from entry to entry within a set of contributed values.
@dgasmith
What about:
- Scalars -
{"type": "array", "shape": (-1, )} - 3-component dipole -
{"type": "array", "shape": (-1, 3)} - Gradient list -
{"type": "list", "item": {"type": "array": "shape": (-1, 3)}} - Hessian list -
"shape": (-1, -1)- requires some code to support or"shape": "square" - Orbitals - May require external information for each, maybe:
{"type": "list", "item": {"type": "array": "shapes": [(nso, nmo), ...)]}}
Borrowing a bit from the JSONSchema standard.
@loriab We have this problem again.
I guess we can always assume that the leading dimension is the same as the length of index, so
Scalars - {"type": "array", "shape": ()}
3-component dipole - {"type": "array", "shape": (3)}
The list-based items remain unchanged.
{"type": "array", "shape": (-1, )} says I will apply this shape to the array that I am given (the top level one). {"type": "list", "item": {"type": "array": "shape": (-1, 3)}} says I am given list and will apply this shape to each item in that list. Shortcutting it can get iffy.