jrissman
commented
2 years ago I decided to take a stab at this today, thinking it might only take an hour or two. It is turning out to be much more difficult than I anticipated. While only 40 variables contain 4 subscripts, many variables use "Cargo Type" or refer to variables using "Cargo Type." The code in the .mdl file needed to be updated in around 1500 different places. It would have been impractical to do this by hand, so I did most of the updates programmatically, and did the most difficult 400 or so updates by hand.
Unfortunately, that method of updating code is prone to causing bugs, and it took me a while to debug it and get the model to run. After about 8+ hours of work, the model runs, but it's currently producing nonsensical results for the transportation sector. So I would still need to go and find where the equations now don't make sense and fix them.
I think I probably would not have tried this if I'd known how difficult it would be at the beginning. It's almost done now, so I might try to finish it off. But it doesn't actually seem like it's adding much value. It reduces the number of .csv input files a bit and makes some of the equations a bit more readable, and it saves us a subscript on the transportation sector policy levers (where we are capped at two subscripts in the web interface), but these weren't important limits for us before.
On the downside, we're probably adding just as many equations as we remove, because for every place I can remove the "passenger" and "freight" versions of an equation (usually when loading input data), there's some other place where we only had input data by vehicle type (not by Cargo Type), so I need to add six new equations to read the same input files each twice (for example, once for passenger LDVs and once for freight LDVs). So in this specific sense, at least, it isn't really simplifying the model.
It seems like the value is really minimal aside from helping with SDEverywhere development. So much so that I'm not sure if I should even merge this work (all done in branch 174) into the main develop branch. Todd can use an EPS version in a side-branch for testing and developing SDEverywhere just as easily as he can use the main branch. So the SDEverywhere consideration is irrelevant to the question of whether to finish and merge this work into the main branch, or to just leave it in the side branch forever.
robbieorvis
There is no benefit to having a separate "Cargo Type" subscript, and there are a number of drawbacks, particularly as we no longer wish to use passenger and freight versions of aircraft and ships (per issue #153), and we never used freight motorbikes (often repurposing it to another vehicle type, such as "three-wheelers" in India). We could extend the "Vehicle Type" subscript to handle all the vehicle types now being handled by Vehicle Type and Cargo Type (e.g. a 1x12 matrix instead of a 2x6 matrix).
As of now (7/8/21), EPS version 3.3.0 contains only 40 variables that use four subscripts. (No variables use more than four subscripts.) All 40 of these variables include the "Cargo Type" subscript, so no variable in the EPS would have more than three subscripts if we merge "Cargo Type" into "Vehicle Type."
The number of subscripts per variable is relevant because SDEverywhere, a tool for transcoding Vensim models into WebAssembly, currently only supports models that contain variables using no more than three subscript dimensions on a single variable. We could not live with this restriction forever, as we will need to add four (or more) subscripts to specific variables in the future. However, it would enable EPS 3.3.0 to more easily work with SDEverywhere and could be used as a testing platform to help SDEverywhere add support for higher numbers of subscript dimensions per variable.