Apply virtual material densities to microscopic tally results

[paulromano]

Description

This PR is an alternative to #4027. It adds an in-place Tally.apply_virtual_material() method for applying the
nuclide atom densities of an openmc.Material to tally results generated with multiply_density=False. This supports calculations such as determining dose in silicon when silicon is not present in the transport model. The method preserves the tally's nuclide dimension, scales all statistical moments consistently, and assigns zero density to tally nuclides absent from the virtual material. The new method only requires 60 lines of code, most of which is just documentation/error checks; the actual implementation is ~15 lines.

I've also added a section in the user's guide discussing the use of virtual materials, showing an example of computing dose in Si.

Checklist

• I have performed a self-review of my own code
• I have run clang-format (version 18) on any C++ source files (if applicable)
• I have followed the style guidelines for Python source files (if applicable)
• I have made corresponding changes to the documentation (if applicable)
• I have added tests that prove my fix is effective or that my feature works (if applicable)

[shimwell]

Ok this PR is clearly much more concise than #4027 which I think we all like 👍
It also avoids one of the issues with #4027 which misused the tally.nuclides or could introduce a new keyword arg 👍

It does appear to me at least to come at a small cost:

• worse variance estimation, combines bins by quadrature, python has no access to covariance terms from the stored data 😢
• an extra single line processing step for the users apply_virtual_material 😢

So it comes down to in this case we value simplicity, maintainability and clean tally inputs over exact covariance-aware collapsed sigma and slightly less user effort.

If it suits we can leave these open for a while to give us a chance to discuss them at the next F4E UKAEA Proxima fusion meeting

[paulromano]

combines bins by quadrature, python has no access to covariance terms from the stored data

apply_virtual_material does not combine bins by quadrature; it simply scales the bins by the appropriate virtual atom densities. Combining tally bins to get a summed response is left as the user's responsibility and is always subject to this limitation in OpenMC; because we don't keep covariances across tally bins, you always have to live with the fact that summing over bins means that you don't have the right estimate of the variance of the sum. So, I wouldn't call that a downside of the functionality introduced here but more just a basic limitation.

Related to this, one downside to #4027 is that it misses out on the ability to break down the response by nuclide.

[GuySten]

What do you think about a keyword argument that decide if we collapse along the nuclide axis or not?