SOLVED: Extending burnSteps case setting to be a vector

[keckler]

From my understanding, right now the burnSteps case setting is just a single value, which is applied to all cycles. This is fine for most cases, but sometimes one might be simulating a reactor with cycle lengths that vary quite a bit, and different cycles would call for different numbers of burn steps. Or you want to examine the isotopics in detail after a burnup, so you'd want to have a fine time mesh for the decay cycles but not for the actual burn cycles. I could propose other use cases as well.

Would anybody have any thoughts on extending the burnSteps setting to allow for multiple values? This would be in line with the cycleLength/cycleLengths or powerFractions case settings.

[jakehader]

I think that this would be a great addition/improvement for the framework. I wonder if it makes sense to also define the number of days for the burnup steps too rather than just the number of steps themselves. For example, cycle length is 365 days, 3 burnup steps, with the burnup step times being 10 days, 55 days, and 300 days rather than just being a uniform 121.6667 days each (365/3).

I think that this support in the framework could help with sensitivity studies on burnup, help with modeling specific benchmarks, and help to add further depletion support for LWRs.

[keckler]

Thanks for the feedback.

I actually don't know if this would need to be a breaking change. I imagine that we could make the various case settings mutually-exclusive with each other such that the user could either provide their cycle input in the old format or supply the new data structure. So existing inputs would continue to work.

[john-science]

Sorry, I just realized I hadn't commented on this.

I like the idea. It has a clear purpose and benefit.

I can't think of any particularly tricky problems implementing this. If there is some issue that would make this a big task and not a small one, I can't think of it at the moment.

[keckler]

I can put some effort into implementing this in the next week or two.

[keckler]

Okay, well I take it back. This will have to be a breaking change, from what I can tell.

It is not going to break the user's cases, but rather I think it will break a bunch of plugins, primarily because burnSteps is stored as a case setting and is always accessed through the self.cs["burnSteps"] syntax. In order to make it variable, it would need to be stored on the operator and accessed via self.r.p.burnSteps syntax instead, so that the current cycle can be known. This is how powerFractions and availabilityFactors are stored and accessed right now.

So I don't know exactly the best way to go about doing this right now...

[ntouran]

I think vectorizing burnSteps to be consistent with cycleLengths, powerFractions, and availabilityFactors makes all the sense in the world. Those each have two settings (e.g. cycleLength and cycleLengths) that allow users to input one unchanging one or a cycle-wise vector. In both cases, a list with values for each cycle is created and stored on the operator.

For this case, I guess keeping the existing setting would be convenient for not breaking backwards compatibility of input files, and we'd want to make an additional setting for providing a vector input. Ideas:

• burnStepsByCycle?

And yes you'll have to :s/self.cs["burnSteps"]/self.r.p.burnSteps everywhere that uses it.

Along these lines, while making this new parameter and setting, would it be worth attempting to make it a better name? burnSteps is a bit unconventional. Perhaps subcycles? You could actually do this while maintaining compatibility with old inputs:

New settings:

• numSubcycles
• numSubcyclesByCycle

new reactor parameters:

• subcycleNum

New setting migration:

• map value from burnSteps to numSubcycles

Regarding days vs. numbers, that is probably convenient. I recommend that be considered as a separate discussion and development. That could be handled as just an alternate setting that can be used mutually exclusively with e.g. numSubcycles, etc.

[keckler]

This has been resolved: #637