Giters

calliope-project / calliope

A multi-scale energy systems modelling framework

Home Page:https://www.callio.pe

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Feature: allow for complete math overrides

irm-codebase opened this issue · comments

commented

What can be improved?

As of now, builds custom math "on top" of the pre-defined math.

While this is good to simplify the way users interact with Calliope, it introduces problems in cases were the math needs to be heavily modified since users have to essentially look in two different places and are limited by what we put in the base math.

I'd like to propose a simple override were users introduce the "base" math file themselves (with no guarantees from our side).

This would make the library much more flexible, and may even allow others to discover improvements to our base math.

Version

v0.7

commented

To do so, here are the steps I've identified:

  • add config.init.add_schema to allow users to specify additional schema files for their settings. update_model_schema is no longer necessary (but it is optional).
    • To allow this, config.init must be included in the saved model attributes (until now it's excluded).
    • MODEL_SCHEMA is now a model attribute (or is generated from them on-demand). Other schemas remain the same since they target file structure and not parameter defaults.
  • add config.init.base_math, a boolean that makes the model ignore the base math / schema when set to false.
  • move the _add_math step to build, since it is not really necessary for model initialization. This should let users make corrections on the fly without re-initializing model data, or to test the same model data with different math formulations.

The general idea is to let users remove the base math and specify everything on their own, if they choose to do so.

commented

This issue is related to two different things: base math overriding and easier access to the model definition schema.

The model definition schema only controls the definition of parameters, it has no bearing on the math or the config (they are both different schema files). Hence why it isn't really linked to overriding the base math.

commented

The math and config schema should not be user-configurable in any way. Changes to those will likely cause things to break elsewhere.

commented

@brynpickering I agree that the config_schema.yaml and math_schema.yaml should not be altered by users. I think the confusion was caused because I'm unfamiliar with the names people often use for things.

This PR is only about model_def_schema.yaml (what you call the model definition schema) and base.yaml.
When it comes to these, I disagree: if you are replacing base.yaml, you should also replace the parameter definitions!

It does not make sense to allow removing the math formulation constraints and still have presets on the parameter side. In reality, users going this way are likely to re-use a lot of it, but it still should be a separate file.

commented

I've introduced #609, which only targets skipping base math.
Depending on what is agreed upon, I could work on a separate PR for the add_schema parameter.