Improve and advance data structure checks

[mihlema]

Currently, new users are often challenged with a plethora of cryptic error messages, when missing essential elements to SpineOpt. The goal of this issue is to identify common pitfalls, and capture those with explanatory Errors (or warnings if SpineOpt applies some defaults).

Generally, we can divide input errors into two categories: parameter and object/relationship input errors.

For parameter input errors, the main way forward is to check whether the entered parameter type corresponds to the required parameter type (e.g. duration value for the roll_forward parameter etc.). From toolbox side, this functionality has recently been added (@manuelma?). On top of that there are some logical checks can be added:

• model_start<= model_end
• max_ >= min_... (ramps, ratio...)
• min_operating_point <= 1
• (to be extended)

For object/relationship classes, especially fundamental relationship can be checked:

• model -> if no model exists error
• node/connections/units with out any relationships to other nodes/connections/units -> @warn "isolated"
• candidate node/unit/connection not connected to investment temporal block -> @error
• stochastic_scenario not defined -> auto create deterministic scenario + @warn
• stochastic_structure not defined -> auto create deterministic scenario + @warn
• missing stochastic_structure__stochastic_scenario not defined -> auto create relationships + @warn or @error? For deterministic case this would be okay, for more complex stochastic structures, I think an @error would be safer
• missing model__temporal_block (warn already in place)
• (to be extended)

*Alternatively, the output objects could be native to the template - users would need to delete undesired outputs)

[Tasqu]

On the SpineOpt telco on the 2021-08-25, @KristofPhillips95 asked for some more ideas for potential input data checks, so here are my immediate thoughts after browsing through the SpineOpt template. Note that some of these might already have checks in place! I didn't bother to check the code.

Object classes

For most of these, it's probably worth to check if any exist and are connected to at least one model object via any appropriate relationships. I don't have much to add to suggestions by @mihlema above.

Relationship classes

Personally, I'm not sure if I would auto-generate any stochastic structures, but if we want to go the extra mile, why not. As long as a warning is thrown so that things aren't done without informing the user.

For the temporal/stochastic structure, every node, units_on, units_invested etc. must be connected to both a stochastic_structure and at least one temporal_block. That, or a default must be in place via the model_default_... relationships.

• [ ] Check that any report has connected output via report__output, at least for all model__report?`
• [ ] Check that every unit_constraint has at least something included in it?

Object parameters

In general, a lot of investment parameters lose their meaning, unless the entity in question has investments enabled. Anyway, here's a list of things that came to mind:

• [ ] node parameter fix_node_state requires that has_state=true, meaningless otherwise.
• [ ] node parameter frac_state_loss requires that has_state=true, meaningless otherwise.
• [ ] node parameter state_coeff requires that has_state=true, meaningless otherwise.
• [ ] temporal_block parameter block_end > block_start.
• [ ] temporal_block parameter resolution > 0 (might be implemented already?)
• [ ] unit parameter fix_units_invested is meaningless if unit has no investments.
• [ ] unit parameter fix_units_invested_available is meaningless without investments.
• [ ] unit parameter fix_units_on is meaningless without units_on (not sure if units_on can be disabled in SpineOpt?)
• [ ] unit parameter unit_investment_cost is meaningless without investments.
• [ ] unit parameter unit_investment_lifetime is meaningless without investments.
• [ ] unit parameter unit_investment_variable_type is meaningless without investments.

Relationship parameters

In general, ramp and reserve parameters are meaningless without ramp/reserves enabled. (not sure if they are separately enabled somewhere?)

• [ ] node__node parameter diff_coeff requires that both nodes have has_state=true.
• [ ] max_res_shutdown_ramp > min_res_shutdown_ramp, an other similar max-min value pairs regarding ramps.

[KristofPhillips95]

Also add checks for duration/Datetime values

• [ ] Temporal block resolution

• [ ] Roll forward

• [ ] ...

• [ ] Walk through template and check when type is duration --> then check existing parameters

[clizbe]

Closing due to stale status.

[clizbe]

Closing because stale.