Tally derivatives

Hello, I’m new to using tally derivatives, and I wanted to ask a few questions since the documentation is a little sparse. I’ve been playing around with it, and it’s not necessarily behaving the way I expect.

Is the tally derivative in addition to the regular tally? i.e. If I want both the score and its derivative, do I need to create two separate tallies, or can I access both pieces of information from the same tally?

How do filters interact with the tally derivative? I see the derivative requires a material id. If I also use a mesh filter, will I expect different results in each bin?

What is the range covered by the temperature derivative? Should I recalculate the derivative for a different temperature profile, or is it robust across a large range?

I’m hoping @sterling_harper will see this and provide some help!

Thanks!
Miriam

Hey @mkreher13! I’ll try to give an answer but obviously @Sterling_Harper1 would know better.

Tally derivatives apply to all scores in the tally, so if you wanted a normal score and its derivative, you would indeed need to create two separate tallies.

Derivatives and filters operate completely independently of one another. Derivatives are applied to scores right before the point where they are accumulated in the tally, whereas filters provide a weighting factor that is computed independently (usually 1 or 0, but it can be something else – e.g., the fraction of a path within a given mesh element).

Good question; I’m not sure one can assume that it would be robust over a large range. I guess it would depend on the second derivative with respect to T. The best thing to do would be to test it out to see how the derivatives change with temperature.

I can chime in on this one! @paulromano just hit the first two points, but I’ll reply to them all for completeness.

It’ll just give you the derivative so yes you would need two separate tally objects to get both the normal tally and its derivative. It would be nice to change that behavior, but I think it would also be tough to change because we’d probably have to modify the MPI communication code in order to efficiently tally both quantities in the same object.

The way I think of it is that we’re computing dy/dx and the filters tell us the exact y that we’re tallying and the derivative object tells us the exact x that we’re tallying.

So for example, if we have materials 1 and 2 then we can tally the absorption rates in each material as rate_1 and rate_2. We can also compute the derivative of those reaction rates with respect to the density of material 1 to give us d_rate_1 / d_rho_1 and d_rate_2 / d_rho_1. In other words, the code would estimate how much a density change in material 1 would affect the reaction rates in each of the materials 1 and 2. (That would be a tally with a material filter specifying materials 1 and 2 and a derivative specifying material 1.) You could also make a separate derivative tally to compute d_rate_1 / d_rho_2 and d_rate_2 / d_rho_2.

Note that the code will also disallow certain combinations of derivatives and filters because the underlying variables are inter-dependent. For example, changing temperature will change the output energy distribution from neutron scattering events. The code doesn’t know how to account for that so it will produce an error if you combine a temperature derivative with an EnergyOut filter.

Also, it’s worth noting here that the derivatives are just an estimate and their accuracy will depend on the choice of filters. If you’re tallying the reaction rate in a small region that’s far away from the material that you’re perturbing, then the answer will be off because the code doesn’t account for change in the fission source distribution. (I usually get around that issue by computing the derivatives of cross sections rather than reaction rates which cancels out much of the error.)

It’s hard to give a general answer there, but when I’m doing PWR multiphysics I usually find that the second derivative is significant over the ranges of interest. Even on something simple like the Mosteller benchmark, I find significantly different derivatives of d_k_eff / d_T between 600 and 900 K.

Thank you both for these answers! Very helpful as I dive into using tally derivatives. I’ve been playing around with them, and I think I understand the mechanism. It got very reasonable results with a ‘flux’ score. However, I am aiming to use tally derivatives on a ‘fission-q-recoverable’ score, and the results don’t behave as a I expect. Is there anything about the ‘fission-q-recoverable’ score that would make it incompatible with tally derivatives?

Ooh, it looks like that might be a bug! I never implemented a derivative for that score. In the function “apply_derivative_to_score” it looks like most of the code branches like that will error out a message with “Tally derivative not defined for a score on tally …”, but that error message is missing for temperature derivatives with collision estimators. I’ll add that error message to my to-do list.

I’m a little rusty so I’d have to think about it for a bit to figure out it it’s easy to implement the fission-q-recoverable score. If not, I bet you’d get decent results by computing the derivative of fission and multiplying it by the ratio of fission-q-recoverable / fission (from a normal, non-derivative tally).

Thanks for confirming that this won’t work for fission-q-recoverable. I definitely like your recommendation to use fission instead. Sounds like that should work well for me.

Thank you!!