[Feature] Allow `DeployInst` to declare a different start year than the simulation

[gonuke]

What is the motivation for your feature request? Please describe what you want to use it for.

Some simulations rely on a DeployInst to define complex deployment histories of individual facilities over time. It can be convenient to have those defined in an XML code snippet and then include them in other simulations. However, the timing of deployment in a DeployInst assumes some given first year of the simulation.

Describe the feature you'd like.

This could be remedied by allowing DeployInst to define a different start date for its own timing (default is the same as the simulation start date for backwards compatibility). All the deployment/decommissioning times would be shifted by the different between the simulation start time and the DeployInst start time, with all facilities guaranteed to be started at the first time step if the shift causes a negative deployment time.

Describe alternatives you've considered.

Force users to make sure they have deployment/decommissioning times that are consistent with the simulation start time in their XML snippets.

How can this issue be closed?

Add an optional field to DeployInst and the logic to set the deployment/decommissioning times correctly.

[meg-krieg]

Has this issue been taken yet? I have some ideas about how to get this implemented, and I would like to take a look.

[gonuke]

I've assigned it to you @meg-krieg - happy to chat more about strategies for completing this.

[meg-krieg]

Hi, I have a decent idea about how to tackle the shifted deployment time, but I wanted to run it by you and also discuss the shifted decommissioning time. For shifted deploy time, I was planning to introduce a new optional, xml-input variable, deploy_year, into deploy_inst and depending on the magnitude of deploy_year relative to the simulation start year + duration, the build_times for the prototypes would be shifted or reset to the simulation start time-step.

Example

• simulation duration > deploy year > simulation start year , then t = prototype build time + deploy year offset
• deploy year < simulation start year, then t = simulation start step
• deploy year > simulation duration, then throw error

I guess some difficulty comes in with accounting for decommissioning being shifted by a deploy_year. From what I understand, setting the prototypes lifetime allows it to track its own decommissioning schedule? The current deploy_inst feature allows users to optionally reset the lifetimes that were previous assigned in the facility xml blocks. By incorporating the deploy_year feature, should I also be making some changes to the deploy_inst code surrounding prototype lifetimes?

Changing the prototype lifetime could be complicated as there are a lot of different scenarios: deployinst lifetimes set + deployinst deploy_years set, or deployinst lifetimes set and deployinst deploy_years not set.... etc. Along with all the different deploy_year scenarios in the Example above.

Is there a better way to shift the decommissioning rather than through altering the prototype lifetime in the deploy_inst? I have thought of a scenario where I edit the actual lifetime function in agents but that would require some changes to the Cyclus repo.