Closed robfairh closed 5 years ago
can you show me the input xml for the d3ploy institution section of the input file?
This is it for both input files:
The input files are here: https://github.com/robfairh/transition-scenarios/tree/experimental3/input/eg01-eg29
It’s not obvious to me what is the issue. Maybe you need to do some debugging in the source code?
Let's go into the code and do some debugging @robfairh
I run this file
And even though it doesn't use d3ploy, it doesn't have the tables timeserieddemandlwrpu and timeseriesdemandmoxpu:
So @FlanFlanagan was right, the issue is something in cycamore and the way the tables are recorded.
Even though having those tables makes life easier, I am not sure they are needed by d3ploy to deploy the right thing. This continues on my next comment.
To make things simpler I made the following inputs:
1) nond3ploy-simple.xml: https://github.com/robfairh/transition-scenarios/blob/experimental6/input/eg01-eg29/nond3ploy-simple.xml
2) d3ploy-simple1.xml https://github.com/robfairh/transition-scenarios/blob/experimental6/input/eg01-eg29/d3ploy-simple1.xml
3) d3ploy-simple2.xml https://github.com/robfairh/transition-scenarios/blob/experimental6/input/eg01-eg29/d3ploy-simple1.xml
4) d3ploy-simple3.xml https://github.com/robfairh/transition-scenarios/blob/experimental6/input/eg01-eg29/d3ploy-simple3.xml
1)Doesn't use d3ploy, it's just the nond3ploy version, I deployed everything manually. 2)Not very important, but it just deploys sinks to see that d3ploy works with the input. These two work fine. 3)the mixer is deployed using d3ploy. The table timeseriescalc_capacitylwrpu is 0 at all times. This causes the simulation to deploy new mixing facilities at all times. For this case, the mixer has two inputs for Pu lwrpu and frpu.
4)the mixer is still deployed using d3ploy. This time, the mixer has only one input for Pu, lwrpu. This time calc_capacitylwrpu is 3000. And it deploys only one mixer. Of course this transition doesn't work because it won't use frpu, but the case helps to show what d3ploy is doing.
It works well when I used the feature "installed_capacity" (thanks, @gwenchee), now the issue could be closed when the predicted capacity feature works as well.
Using installed capacity still has issues with the full input:
The capacity of the frmixer is 13e3 and the capacity of the moxmixer is 8e3. The supply of Pu is 20.8e3 then it deploys 1 frmixe and 1 moxmixer. The capacity should be 21e3, but the table shows just 8e3. Then on the next time step where there is a supply of Pu, it deploys 2 more moxmixer, the table shows a capacity for lwrpu of 24e3. The table is just recording the capacity of one of the prototypes (moxmixer) deployed by d3ploy. Both frmixer and moxmixer are supply driven deployed by the same commodity: lwrpu.
In the beginning it wasn't clear what the issue was. After looking into it, we found that this issue can be decoupled into 3 smaller issues. This issue is closed, and the 3 issues are open. These are #270, #273, #274.
For the case where the mixer has only one input for a commodity (in this case Pu):
The table timeseriescaclc_capacitylwrpu is the following:
When the mixer takes more than one input for the Pu:
The table timeseriescalc_capacitylwrpu becomes 0 at all timesteps:
The obvious consequence of this is that d3ploy sees that the capacity is 0 and deploys a new mixer everytime there is lwrpu available from the reprocesing facility.