Update Okapi to newest version of OpenMC

[aprilnovak]

We will want to create a more up-to-date branch of OpenMC to use for coupling, but in order to do so we will need to incorporate any other additional changes to OpenMC routines called in Okapi. This will involve updating the error codes and incorporating the new functional expansion filters into the custom routines currently in aprilnovak/openmc/zernike-error-codes-c-api.

[lindsayad]

@aprilnovak Is this a priority for you? If you have other priorities, I can take a look at this

[aprilnovak]

If you want to take a crack at it, that'd be great! I had started this last week before ICAPP (see the started-openmc-update branch), but it's still incomplete. This branch won't compile unless you comment out my specific routines that aren't in the newest OpenMC.

To summarize the major changes in OpenMC that have occurred:

• changes in how error codes are handled. Previously, we had lots of different error codes, but these have been simplified to a smaller number of codes, and OpenMC forms its own error messages that are passed to MOOSE (so I updated the error handling routines for OpenMC function calls). I wanted more information to be printed from MOOSE error codes, so I append extra strings to these messages. A cleaner error printing class could be constructed.

• switched to using OpenMC's openmc_get_keff routine instead of the simple one created specifically for Okapi

• FE filters have been implemented. Ideally, I want to delete the fet_deconstruction, get_coeffs_from_cell, and receive_coeffs_for_cell routines and only use routines in the C-API in OpenMC, since lots of new routines have been added that allow an external code access to more tally information. A few more routines might need to be added... For example, if we want to specify coupling information based on the OpenMC cell ID (as it currently is), then we might have to add routines to return a list of tally IDs that have a filter over the requested cell ID, then pass that to another routine that returns the list of tally IDs that also have FE filters, etc. There's also lots of room for improvement in terms of saving the coupling information (like, what tally ID corresponds to the FE tally on my requested cell) for re-use in each Picard iteration instead of performing the search each time. I haven't started this process at all, so whatever approach you think works best would be great!

[lindsayad]

Just wanted to let you know that I'm working on this and (I feel like) I'm making good progress. Hope PHYSOR is going well!

[aprilnovak]

Great! PHYSOR presentation is finished, so now I have one day left to enjoy the beaches :) I have all of May free since classes are over, so should more active once I'm back.

[lindsayad]

@aprilnovak A problem I'm seeing is that with an update to a newer version of OpenMC and the new tally system, I get exodiffs in the pin-cell test because I believe the simulation is run slightly differently, e.g. different order of events. This leads to different random numbers being applied to different particle histories and consequently different tallies.

The current Monte Carlo input for that test yields a kappa-fission distribution that is more or less "random", e.g. the distribution of fission events is physically flat, so with relatively few batches and particle histories we're liable to see a different mottled distribution (see below) yielded by the Monte Carlo simulation depending on the seed.

Maybe a better test would be to use an input that delivers more of a shape to the kappa distribution, e.g. maybe a problem with vacuum boundary conditions such that we get a sinusoid. Then perhaps instead of using an exodiff test (still liable to pick up small Monte Carlo fluctuations), we could use a combination of postprocessors and/or line vector postprocessors and use a CSVDiff or something that yields a more robust testing framework against different seeds (or different OpenMC versions).

What do you think?

[aprilnovak]

I think that's a good idea. The postprocessors could pass based on some criteria like the L-2 norm of the FE versus a sinusoid being smaller than some tolerance. If you run this test as-is with tons of particles, the FE distribution shows a rim effect, which I think occurs due to self-shielding (thermal neutrons coming from the water being more likely to fission right away in the outer ring of the fuel). But that doesn't become visible unless you use way too many particles for a test.

Sorry for the delay, I'm at a conference in Nashville - I can help out with whatever might be needed starting Thursday.

[lindsayad]

I think that's a good idea. The postprocessors could pass based on some criteria like the L-2 norm of the FE versus a sinusoid being smaller than some tolerance.

I like this idea.

If you run this test as-is with tons of particles, the FE distribution shows a rim effect, which I think occurs due to self-shielding (thermal neutrons coming from the water being more likely to fission right away in the outer ring of the fuel). But that doesn't become visible unless you use way too many particles for a test.

Yes, I've seen that; makes sense.