Equivalent of args_spec for model outputs

[emlys]

As we've discussed related to the recent ARGS_SPEC changes, it would be nice to have a similar data structure for each model's intermediate and final outputs.

This would store similar information, and we could reuse most/all of the ARGS_SPEC design:

• file name and corresponding variable name
• description
• units
• projection (which input projection does it inherit)
• vector geometries and fields

Outputs only use a subset of the possible input types and don't need validation, so really it will be simpler.

As an example of why this would be useful, today I discovered the SDR user's guide doesn't mention a dozen of the intermediate outputs. Without a central source of information, it's pretty tedious to figure out what they represent. We could generate this documentation like we are starting to do for the model inputs.

Another use case would be in a workbench data viewer, we would need to access units and descriptions mapped to output file names. This information currently doesn't exist in any structured format.

Unlike the recent ARGS_SPEC updates, this is not a priority to happen before translation, because this info is not duplicated (exists only in the user's guide, if anywhere).

[davemfish]

I think this will be very useful. Especially for documenting the units of output variables, which we are often asked about. We'll need to be careful to keep things like units, fieldnames, etc accurate and current with the actual implementations. But most of invest is stable in that regard and not subject to change.

today I discovered the SDR user's guide doesn't mention a dozen of the intermediate outputs.

I think this is typical. I think UG authors (speaking for myself) have often used their judgment to decide which data should be described in the UG and which should be completely omitted because the data is only written for memory-management purposes, or something similar, and users would never need/want to look at it.

[emlys]

@davemfish good to know that some of that just isn't relevant to users! I would still be in favor of including it in an output spec, in case anyone wants to know more

[emlys]

We should let Stacie and Jesse know when we're starting to work on this in case they would like to edit some outputs sections in the UG first.

[emlys]

We discussed the design doc together over 2 coffee calls and answered some questions. We'll figure out the few remaining, small unknowns as we go.

[emlys]

This was implemented in #1216. While there's more we can do with it, I think the original issue has been solved.