WP2 to SpineOpt Conversion tool

[DillonJ]

There is a lot of discussion regarding unit conversions and making them nicer for users and also a related issue discussing modelling certain things like reserve and inertia explicity #774

My key concern in all of this is that currently the ideas in SpineOpt are quite simple once you get your head around them. We can do anything with units, connections and nodes. This is the flexibility of SpineOpt that makes it a great too for studying the energy transition - a user can define all sorts of new energy carries, technologies, services etc. very easily. This was a fundamental idea behind SpineOpt in the very first instance - I think it's a defining characteristic.

The challenge is that for non-expert users, the cost to this flexibility is it takes a little bit more work to do familliar things and there's a learning curve - but my experience is that people grow to greatly appreciate once they get there.

I feel we need a well thought-through approach to implementing the nice-for-user features in a way that doesn't compromise the SpineOpt flexibility that people appreciate. My thinking is that the place for this could be the tool that transforms the Mopo WP2 into a SpineOpt model. For example, in this tool, users can specift inertial_constribution for a unit, but in SpineOpt this gets translated into a node (the inertial requirement) and a unit_capacity (the unit inertial contribution). This way we can provide a lot of familliar and nicely named data and keep the general structure of SpineOpt. This then leaves the door open to users to then take the resultant model and add new vetors, sectors, technologies and services to study their interesting energy transition problems.

For example, what we do often is create a master excel workbook that contains all our data that is described in very familliar terms and then write an importer in julia and/or python that does the translation to SpineOpt. It's quick and easy to do. But we could do something along these lines that connects WP2 data to SpineOpt. This avoids complicated pre-processing in the core SpineOpt code that is already getting quite messy. In effect, this proposal really amounts to pre-processing outside SpineOpt rather than inside it - this keeps the SpineOpt implementation generic and simple and easier to maintain while providing all the nice-for-users things that are needed