Adding DeployInst Start Year Features (after and during simulation) by meg-krieg · Pull Request #677 · cyclus/cycamore

meg-krieg · 2026-01-29T21:48:14Z

Summary of Changes

I added a optional deploy year variable to DeployInst. This variable will allow the user to input a year that informs DeployInst of when facilities should be built relative to the build times. It is essentially an offset to build time.
The current changes should anticipate whether the optional deploy year and build time exceed or are within the simulation duration. A value error should be thrown in the event the combination of deploy year and build time exceed simulation duration but the offset is still applied.

This PR does not yet address issue #674 but it does anticipate that users could input a deploy year and build time that is before the simulation start. In this scenario, the time of deployment is reset to time step 1 and a value error thrown highlighting this reset.

Design Notes

I kept deploy year as an optional parameter but this means that build time + deploy year combination must together be considered when evaluating when a facility should be built. For example, deploy year could be within the sim duration but build time offset makes it exceed duration. Or, deploy year could be before sim duration but build time offset makes it within the simulation.

Check the box if your change does not break any of the following:

API for Cyclus modules
Input files
Output tables for post processing tools

Related CEPs and Issues

Fixes #676 and #675

Testing and Validation

Added two tests. One tests whether build time + deploy year falls on the expected year with in the simulation and deploys. Another test checks whether or not build time + deploy year falls before the simulation start and that the deploy times are properly reset to simulation start.

As an aside, I am slightly unsure about the conversion from year to time-step in the code changes.

I have read the Contributing to Cyclus guide
I have compiled and run the code locally
I have added or updated relevant tests
I have added documentation for new or changed features
This code follows the style guide
I have updated the changelog

Reviewers, please refer to the Cyclus Guide for Reviewers.

github-actions · 2026-01-29T21:53:15Z

Build Status Report - `8cb94d7` - 2026-02-04 18:01:19 +0000

Build `FROM cyclus_20.04_apt/cyclus:latest`

Cycamore: Success ✅
Cymetric: Failure ❌

Build `FROM cyclus_20.04_apt/cyclus:stable`

Cycamore: Failure ❌
Cymetric: Skipped due to upstream failure ⚠️

Build `FROM cyclus_20.04_conda/cyclus:latest`

Cycamore: Success ✅
Cymetric: Failure ❌

Build `FROM cyclus_20.04_conda/cyclus:stable`

Cycamore: Failure ❌
Cymetric: Skipped due to upstream failure ⚠️

Build `FROM cyclus_22.04_apt/cyclus:latest`

Cycamore: Success ✅
Cymetric: Failure ❌

Build `FROM cyclus_22.04_apt/cyclus:stable`

Cycamore: Failure ❌
Cymetric: Skipped due to upstream failure ⚠️

Build `FROM cyclus_22.04_conda/cyclus:latest`

Cycamore: Success ✅
Cymetric: Failure ❌

Build `FROM cyclus_22.04_conda/cyclus:stable`

Cycamore: Failure ❌
Cymetric: Skipped due to upstream failure ⚠️

Build `FROM cyclus_24.04_apt/cyclus:latest`

Cycamore: Success ✅
Cymetric: Failure ❌

Build `FROM cyclus_24.04_apt/cyclus:stable`

Cycamore: Failure ❌
Cymetric: Skipped due to upstream failure ⚠️

Build `FROM cyclus_24.04_conda/cyclus:latest`

Cycamore: Success ✅
Cymetric: Failure ❌

Build `FROM cyclus_24.04_conda/cyclus:stable`

Cycamore: Failure ❌
Cymetric: Skipped due to upstream failure ⚠️

gonuke · 2026-02-02T13:04:58Z

Thanks for taking a shot at this @meg-krieg.

It looks like you've taken an approach of allowing each facility to have a different deployment year. However, the intent of the issue - although perhaps not clear - was declare a single "year 0" for the entire DeployInst and then adjust each of the otherwise declared deployment times by the difference between the "year 0" of the DeployInst and the "year 0" of the simulation.

This approach will provide much of the same functionality that your solution provides, but with a single additional and optional entry for the DeployInst.

meg-krieg · 2026-02-04T16:41:34Z

Thanks for the comment! I think I have updated it how you describe. There is only 1 deployyear accepted, and it offsets all the prototype build_times by the same number. I replaced the value warning with an error (mentioend in #674) for before simulation deployment and adjusted any unit tests.

CHANGELOG.rst

gonuke

This is definitely a better match to what I had in mind. Thanks @meg-krieg !!

A few suggestions here to simplify/streamline the code and add more tests.

gonuke · 2026-02-05T00:01:46Z

src/deploy_inst.cc

+    int sim_start = 12*(context()->sim_info().y0) + 
+                            context()->sim_info().m0;


This calculation can move outside/before the loop. In fact, it may be preferable to calculate
delta_t = deployyear*12 - sim_start
before the loop and then use that below.

gonuke · 2026-02-05T00:06:28Z

src/deploy_inst.cc

+                            context()->sim_info().m0;
+    int t_build = build_times[i]; 
+    if(deployyear > 0){
+      if(t_build + deployyear*12 < sim_start){


Or... if you have already modified t_build as suggested above:

Suggested change

if(t_build + deployyear*12 < sim_start){

if(t_build < 0){

gonuke · 2026-02-05T00:07:47Z

src/deploy_inst.cc

-    int t = build_times[i];
+    int sim_start = 12*(context()->sim_info().y0) + 
+                            context()->sim_info().m0;
+    int t_build = build_times[i]; 


if delta_t as recommended above:

Suggested change

int t_build = build_times[i];

int t_build = build_times[i] + delta_t;

Does this imply that start year should now be a required parameter? I left line t_build = build_times[i] before the loop for the scenario where the user does not specify the deployyear and t_build must remain a default.

If the t_build = build_times[i] does need to stay, I could still move some of the calculations out side of the for loop and adjust the if-statements as suggested for streamlining!

Good catch... If deployyear is optional, then it will have a default value. We probably should think about a way to recognize that default and then set delta_t to 0 when the value is the default.

It could be that we can set the default value as the simulation start year when we read that part of the input... but I'll have to think about that...

gonuke · 2026-02-05T00:09:24Z

src/deploy_inst.cc

+     else {
+        t_build += deployyear*12 - sim_start;
+        if(t_build >= context()->sim_info().duration) {


if you have already modified t_build as suggested above:

Suggested change

else {

t_build += deployyear*12 - sim_start;

if(t_build >= context()->sim_info().duration) {

elif(t_build >= context()->sim_info().duration) {

gonuke · 2026-02-05T00:10:21Z

CHANGELOG.rst

+* Added new variable to Deploy Institution to shift the deployment times (#677)
+* Added new tests for Deploy Institution year (#677)


These are probably better as a single entry since new tests are expected as part of any new addition

Suggested change

* Added new variable to Deploy Institution to shift the deployment times (#677)

* Added new tests for Deploy Institution year (#677)

* Added new variable to Deploy Institution to shift the deployment times (#677)

gonuke · 2026-02-05T00:13:41Z

src/deploy_inst_tests.cc

can we add tests for the warning and the error?

Note - we have a pattern for testing for warnings where we use a method that temporarily treats warnings as exceptions

meg-krieg added 19 commits January 12, 2026 09:54

adding new XML file inputs

fa9f8b3

adding new XML file inputs

9fff0d5

fixing spacing issue

f33a1d0

adding the docs info

927cc93

changed variable name so it doesn't match controls

46f9409

adding conditionals for different deploy times

80c7809

simulation start year is t=1?

71a9e22

default deployyear checks

883e8b7

deleted print statements

7121d35

readding throw error statements

25cc758

error throw punctuation fixed

dd06c02

back to t=0 start

e470357

same units for t

e2bf3ca

new scenarios for deploy

cd86ff5

fixed error

b8bf47c

adding deploy year test for within sim bounds

040a935

new tests and adjusting default before-sim behavior

ef2851e

updated additions with deployinst changes

da14347

deleting personal comments

41c832d

meg-krieg requested review from ConnorWelch-OSU, gonuke and munkm January 29, 2026 21:48

meg-krieg added 3 commits February 2, 2026 15:25

start year only happens once

d40db6a

need to change the state variable to in

992ea56

changed unit test to reflect > sim end

5c897f7

deleted comments

c0d22b2

munkm reviewed Feb 4, 2026

View reviewed changes

CHANGELOG.rst Outdated Show resolved Hide resolved

meg-krieg added 2 commits February 4, 2026 09:43

adjusted added features

94779fb

changed some documentation

8cb94d7

gonuke requested changes Feb 5, 2026

View reviewed changes

		int sim_start = 12*(context()->sim_info().y0) +
		context()->sim_info().m0;

	int t_build = build_times[i];
	int t_build = build_times[i] + delta_t;

		* Added new variable to Deploy Institution to shift the deployment times (#677)
		* Added new tests for Deploy Institution year (#677)

Conversation

meg-krieg commented Jan 29, 2026

Summary of Changes

Design Notes

Related CEPs and Issues

Testing and Validation

Uh oh!

github-actions bot commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Build Status Report - 8cb94d7 - 2026-02-04 18:01:19 +0000

Build FROM cyclus_20.04_apt/cyclus:latest

Build FROM cyclus_20.04_apt/cyclus:stable

Build FROM cyclus_20.04_conda/cyclus:latest

Build FROM cyclus_20.04_conda/cyclus:stable

Build FROM cyclus_22.04_apt/cyclus:latest

Build FROM cyclus_22.04_apt/cyclus:stable

Build FROM cyclus_22.04_conda/cyclus:latest

Build FROM cyclus_22.04_conda/cyclus:stable

Build FROM cyclus_24.04_apt/cyclus:latest

Build FROM cyclus_24.04_apt/cyclus:stable

Build FROM cyclus_24.04_conda/cyclus:latest

Build FROM cyclus_24.04_conda/cyclus:stable

Uh oh!

gonuke commented Feb 2, 2026

Uh oh!

meg-krieg commented Feb 4, 2026

Uh oh!

Uh oh!

gonuke left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

github-actions bot commented Jan 29, 2026 •

edited

Loading

Build Status Report - `8cb94d7` - 2026-02-04 18:01:19 +0000

Build `FROM cyclus_20.04_apt/cyclus:latest`

Build `FROM cyclus_20.04_apt/cyclus:stable`

Build `FROM cyclus_20.04_conda/cyclus:latest`

Build `FROM cyclus_20.04_conda/cyclus:stable`

Build `FROM cyclus_22.04_apt/cyclus:latest`

Build `FROM cyclus_22.04_apt/cyclus:stable`

Build `FROM cyclus_22.04_conda/cyclus:latest`

Build `FROM cyclus_22.04_conda/cyclus:stable`

Build `FROM cyclus_24.04_apt/cyclus:latest`

Build `FROM cyclus_24.04_apt/cyclus:stable`

Build `FROM cyclus_24.04_conda/cyclus:latest`

Build `FROM cyclus_24.04_conda/cyclus:stable`