New architecture discussions

[konstantinstadler]

My initial plan is to provide two pysut classes.

1. SUT: very close to the previous SupplyUseTable class with a single V/U for construct and mrsut compilation
2. SUTdev: Closely related to the structure which we have in the exiobase data pipeline. The main difference there are that
   • multiple use layers (basic prices domestic, basic prices imports, margins, taxes ...)
   • in development status: often used as a container to gather data before balancing

I believe that is the cleanest solution. A single SUT class would get quite complicated and convoluted with functions most "SUT Users" dont need. One of the methods in the SUTdev would be to collapse to SUT to avoid any code duplications.

Feedback very welcome.

[rich-wood]

I'm not 100% sure of benefit vs cost of having two classes. It seems reasonable. I'm not sure about what you mean by the in development status - i don't see a massive difference between an "in development" SUT and a balanced one. I would just see these as two instances of the same class?

I think we should make the methods more flexible though, so that e.g. there is more generic switching between coeffs and flows, and that constructs can be applied to any table that fits requirements, not be specified for Use at a minimum.

One other thought would be whether to define the class irrespective of whether it is in flows or coefficients? i.e. instead of having the class define both, we just use different instances for coeffs and flows. I guess there would have to be some restrictions on methods that could be applied to instances of coeffs, but a lot are common.

I often get stuck about what is best in terms of handling value added and final demand as well - whether it is best to have them as part of Use or as separate variables - it can be more efficient handling them as one variable, but also sometimes only the intermediate part is needed - so a clean back and forth there would also be good!?

I'm also not sure of the best organisation of functions, etc. But I see the SUT as a quite generic data container with some quite basic functionality. I see the application of constructs and the generation or MRSUTs as a more specific application that we should be able to apply to SUTs, but are one of many things to do with them.

[konstantinstadler]

i don't see a massive difference between an "in development" SUT and a balanced one:
for me the difference is more the exio sut structure (with 3d use) and the "classical" sut (with 2d use and supply). I am still not sure how to best implement that, 2 classes was a first idea. I am now thinking more in the line of having a module which you can add to the SUT managing 3d use.
There are other implications as well. E.g. I also needed row-based coefficients for the calculation of some values in exiobase which do not have an equivalent in classical SUT calculations.

instead of having the class define both, we just use different instances for coeffs and flows: agree, + something like normalise or make_flows to convert from one to the other

terms of handling value added and final demand as well. I tend toward separate variable, but having a function which returns a "complete" use table (a dynamic variable which builds the full use - property of the class in python)

I see the application of constructs: agree with the data container (in particular for gathering data to get a full SUT). But then, the main purpose was the application of construct (on SUT or MRSUT) to finally get to an IO. Are there things I miss which we should consider already now?

[rich-wood]

all sounds good for first 3 points above.

for the applications (beyond constructs):

• hybridisation
• scenarios
• linear programming (technology choice)
• many macro-economic models just ensure the SUT or IO balance to project consistency into the future. the constructs are really only there to do an allocation as per footprinting or LCA approaches.
• network/SPA analysis - can all be done on SUTs rather than IOs