jrissman
commented
3 years ago The issue you raise here makes sense, but I'm not a fan of the proposed fix. It's a hack or work-around, and the more of those you put into the code, the messier it becomes, which has negative implications for keeping the code maintainable and understandable, and can lead to bugs. (For instance, it can be difficult to know if changing this one variable for this ISIC code would lead to invalid results elsewhere, since there are many places in the code that use ISIC codes, and they were programmed with a particular assumption about what each ISIC code means.) I've tried to be very meticulous over the years to minimize one-off hacks, which is why the simulator is able to be as complex as it is today without being a nightmare to debug or understand.
The core need here is simply an ISIC code split. According to this page of ISIC code definitions, ISIC 05 is "mining of coal and lignite" and ISIC 06 is "extraction of crude petroleum and natural gas". The only reason they are together is because the OECD grouped them in its IO tables. Splitting them up would improve accuracy not only for DCSoCbIC, but for every variable that contains data for ISIC 05-06. So it seems to me like the cleaner way to do this, which won't violate any assumptions elsewhere in the I/O model, would be to split up "ISIC 05-06" into ISIC 05 and ISIC 06. This would be just like when we split up the OECD's grouping of ISIC 20-21 into chemicals (ISIC 20) and pharmaceuticals (ISIC 21), because it was not giving us realistic results when they were grouped.
My memory of splitting up ISIC 20-21 is that it was not an easy task and took me a week of work. Having had that experience already, it would be faster to split up ISIC 05-06, but it won't be super quick. I do not think we should put this into 3.1.1, which is meant to be a very small, incremental update that is released ASAP and that does not involve any changes to input data requirements relative to EPS 3.1.0 (other than FoPITY for the new subscripting of policy levers). But if this issue is more important than the other things we green-lit for 3.2, we might consider doing it alone and releasing it as EPS 3.1.2.
I am going to need to be spending most of my time on ISD over the next year, so we're going to need to be careful about what it's worth doing structurally and what the EPS team can live without.
robbieorvis
mkmahajan
India has significant coal production, but little crude oil production. But coal and crude production are both lumped under ISIC 05T06. In a scenario with lower transportation fuel use, for example, you see a substantial negative change in ISIC 05T06 output, which should be pretty much entirely due to changes in crude demand. That change in output gets multiplied by a DCSoCbIC value of ~0.45, based on OECD data. But looking at our data from BFPIaE, the domestic content share of crude oil consumption specifically is more like 10-15%.
Could we calculate the domestic content of each fuel type using BFPIaE, then use that to swap in a calculated variable for the ISIC 05T06 domestic content share of consumption? We could weight the domestic content of each fuel type by the change in revenue associated with that fuel.
If this makes sense and is straightforward, could we add this to the 3.1.1 update list?