arfc / d3ploy

A collection of Cyclus manager archetypes for demand driven deployment
BSD 3-Clause "New" or "Revised" License
4 stars 11 forks source link

D3ploy doesn't record the capacity of the mixer when it has multiple inputs for a commodity #257

Closed robfairh closed 5 years ago

robfairh commented 5 years ago

For the case where the mixer has only one input for a commodity (in this case Pu):

image

The table timeseriescaclc_capacitylwrpu is the following:

image

When the mixer takes more than one input for the Pu:

image

The table timeseriescalc_capacitylwrpu becomes 0 at all timesteps:

image

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.

gwenchee commented 5 years ago

can you show me the input xml for the d3ploy institution section of the input file?

robfairh commented 5 years ago

This is it for both input files:

image

robfairh commented 5 years ago

The input files are here: https://github.com/robfairh/transition-scenarios/tree/experimental3/input/eg01-eg29

gwenchee commented 5 years ago

It’s not obvious to me what is the issue. Maybe you need to do some debugging in the source code?

gwenchee commented 5 years ago

Let's go into the code and do some debugging @robfairh

robfairh commented 5 years ago

I run this file

https://github.com/robfairh/transition-scenarios/blob/experimental5/input/eg01-eg29/eg01-eg29-flatpower-nond3ploy.xml

And even though it doesn't use d3ploy, it doesn't have the tables timeserieddemandlwrpu and timeseriesdemandmoxpu:

image

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.

robfairh commented 5 years ago

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.

image

image

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.

image

image

robfairh commented 5 years ago

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.

robfairh commented 5 years ago

Using installed capacity still has issues with the full input:

https://github.com/robfairh/transition-scenarios/blob/experimental6/input/eg01-eg29/eg01-eg29-flatpower-d3ploy4.xml

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.

robfairh commented 5 years ago

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.