Problems running a depletion calculation with neutron-photon interaction, for the proper energy deposition calculation and the subsequent proper power normalization

[Augusto Hernandez Solis]

Hello !

So I installed the newest version from the dev branch of OpenMC, and I have the ENDFB71 libraries (with photon data) given by the OpenMC team. If I run the depletion module with the 'energy-deposition' attribute and, at the same time,  I let the code know that I want a photon transport calculation as well (set to 'True' under settings), it gives me a segmentation fault when the transport calculation just begins (attached is the slurm exit with the error, and it seems to be related with the photon transport).

On the other hand, if I just run the depletion module without the photon transport, the depletion calculation runs just fine (both with or without the 'energy-deposition' attribute). I also attached the input file in case you would like to look at it.

This is strange to me because for example, once it crashes, the python input file for depletion still export the xml files (in here, the settings.xml would have the True attribute for photon transport). If I just execute openmc in standalone mode with this xml files, then the code actually is able to run successfully the transport calculation (so the first transport calculation at burnup 0, runs in standalone). Thus, it seems that the problem is with the depletion module wrapping the transport photon-neutron calculation. Any idea what it might be?

Thank you in advance.

Augusto

[Augusto Hernandez Solis]

Update: I think is related to this same issue. Now while depleting, I am trying to run a particle filter (in this case, only the one corresponding to the 'neutron' particle) in order to estimate the energy deposition as a function of burnup in the materials of the domain (also, the 'energy-deposition' attribute is taken into account). In the end, I add a 'heating-local' tally to the exercise (all these is depicted below):

*****************************************************************************************************

tallies_file = openmc.Tallies()
t1 = openmc.Tally(name='edep')
t1.filters = [openmc.MaterialFilter([uo2,zircaloy,borated_water])]
t1.filters.append(openmc.ParticleFilter(['neutron']))
t1.scores = ['flux','fission', 'heating-local']
tallies_file.append(t1)
tallies_file.export_to_xml()

## op = openmc.deplete.Operator(geometry, settings_file, chain_file)
op = openmc.deplete.Operator(geometry, settings_file, chain_file, energy_mode="energy-deposition")

# Perform simulation using the predictor algorithm
integrator = openmc.deplete.PredictorIntegrator(op, time_steps, power)
integrator.integrate()
*****************************************************************************************************

Like this, the code crashes while trying to execute the first transport step (attached is the slurm exit with the error, in case of interest). Now, if I do not use the Particle filter, and only ask for the 'heating-local' tally, the code executes well the depletion calculation until the end,and I suppose it gives properly the heating and other tallies at the step_h5 files (the tallies.out is created and is overwritten at each transport step).

Of course I am not running with photon coupling and, in the end, I do not need for now the particle filter for estimating the energy deposition. However, if you guys solve the issue related to depleting with neutron-photon coupling, then it would be great to tally the energy deposited at each burnup step by the different particles (i.e. photon, electron, positron).

Thanks!

[Paul Romano]

Hi Augusto,

Thanks for reporting this. Yes, it appears that depletion doesn't work with photon transport at present. I'm going to look into getting this fixed and will hopefully have a pull request soon.

Best,

Paul

--
You received this message because you are subscribed to the Google Groups "OpenMC Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openmc-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openmc-users/51c20021-7c75-4bec-b0dc-ef79b2e06d4do%40googlegroups.com.

[Paul Romano]

Hi Augusto,

Just wanted to let you know that a fix for this issue has now been merged in the 'develop' branch of OpenMC. Let us know if you have any further issues.

Best,

Paul

[Augusto Hernandez Solis]

Hi Paul,

Thanks a lot for letting me know. I already tried it. In fact, if I deplete with photon transport, as well as allowing the 'energy-deposition' variable, it works fine (I can even sense how slower the transport calculation is compared to the case when you only have neutrons :-) ).

Just one more thing. It actually seems that the problem related to the ParticleFilter while depleting is still there. I don't even need to activate photon transport to get a seg fault while trying to use a ParticleFilter (meaning that just by neutron transport and not even activating 'energy-deposition', if I use a neutron ParticleFilter the code crashes).

What I want is to tally the different energy deposition per particle while depleting (i.e. neutron, photon, electron and positron) in different cell/materials. On the other hand, if I do not use the ParticleFilter, and then just tally 'heating' using a MaterialFilter and allowing 'energy-deposition' and photon transport, then it is ok; then I could actually get the total energy deposition at different materials using a coupled neutron-photon calculation. As I mentioned to you, I just want to separate such energy deposition contribution per type of particle. It actually seems that either with or without photon transport, the ParticleFilter is only working in transport standalone and not with the depletion module.

Hope there can be a solution for this.

Best regards,

Augusto

On Wednesday, June 24, 2020 at 3:21:08 PM UTC+2, Paul Romano wrote:

Hi Augusto,

Just wanted to let you know that a fix for this issue has now been merged in the 'develop' branch of OpenMC. Let us know if you have any further issues.

Best,

Paul

On Tue, Jun 16, 2020 at 3:52 PM Paul Romano <paul....@gmail.com> wrote:

Hi Augusto,

Thanks for reporting this. Yes, it appears that depletion doesn't work with photon transport at present. I'm going to look into getting this fixed and will hopefully have a pull request soon.

Best,

Paul

To unsubscribe from this group and stop receiving emails from it, send an email to openmc...@googlegroups.com.

[Augusto Hernandez Solis]

Hi again (and sorry for disturbing so much),

I have an inquiry while running the depletion pin case with photon transport. It is running; however, there are some warnings in my slurm output that seem strange to me. As I mentioned in my previous post, there is a problem (a seg fault) if I add the ParticleFilter during depletion. But if I don't add such type of filter and I just ask to tally the total deposited heat, it appears the following warning:

WARNING: Particle filter is not used with photon transport on and flux score.
 WARNING: Particle filter is not used with photon transport on and fission
          score.

I wonder if actually the energy deposition (the one obtained with 'heating' variable) would be properly computed by means of the coupled neutron-photon even if the ParticleFilter is not present.

Another thing; also, during the transport calculation it appears the following (even more than once):

WARNING: Particle 32843 underwent maximum number of events.

I attached both the slurm and the input file that is currently being executed, in case you like to see them.  Now, I found strange the "maximum number of events" warning, because I had already depleted the pin only with neutron transport and such warning never appeared (only appears now with coupled neutron-photon).

Thanks.

Best regards,

Augusto

[Paul Romano]

Hi Augusto -- thanks for your persistence. This is indeed another bug; I've just submitted a fix for it and confirmed that it works for your model (thanks for sharing). Hopefully the fix will hit the develop branch soon.

Best,

Paul

To unsubscribe from this group and stop receiving emails from it, send an email to openmc-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openmc-users/33e8c0a9-469b-414e-a9db-5d965dd2a4bfo%40googlegroups.com.

[Augusto Hernandez Solis]

Dear Paul,

Thanks for letting me know and for your effort in improving the code. I took the liberty to follow the "fix for it" link with the pull request, and I realized that it has been already incorporated into the dev branch (I think so ;-) ). So I took the liberty to download this new version and re-compiled it, and to execute once more the pin depletion case.

Now the ParticleFilter problems have been fixed; in fact, now I can actually even tally the energy deposition at different burnup points (see just below for instance, the output of the tally at the last burnup point, which is around 27 MWd/KgU). Nevertheless, I have to say that I did not like at all the outputs of OpenMC while depleting with neutron-photon coupling (after the particle energy deposition tally, I will keep explaining my founds).

*******************************************************************************

 Material 1
   Particle: neutron
     Total Material
       Flux                                 10.3908 +/- 0.0144308
       Fission Rate                         0.538053 +/- 0.000833752
       Nu-Fission Rate                      1.60297 +/- 0.00247123
       heating-local                        1.07895e+08 +/- 164990.0
       heating                              9.74684e+07 +/- 150815.0
   Particle: photon
     Total Material
       Flux                                 15.7284 +/- 0.756086
       Fission Rate                         0.00000 +/- 0.00000
       Nu-Fission Rate                      0.00000 +/- 0.00000
       heating-local                        0.00000 +/- 0.00000
       heating                              523238.0 +/- 1564.75
   Particle: electron
     Total Material
       Flux                                 0.00000 +/- 0.00000
       Fission Rate                         0.00000 +/- 0.00000
       Nu-Fission Rate                      0.00000 +/- 0.00000
       heating-local                        0.00000 +/- 0.00000
       heating                              9.06618e+06 +/- 13282.7
   Particle: positron
     Total Material
       Flux                                 0.00000 +/- 0.00000
       Fission Rate                         0.00000 +/- 0.00000
       Nu-Fission Rate                      0.00000 +/- 0.00000
       heating-local                        0.00000 +/- 0.00000
       heating                              -26367.6 +/- 1208.43

**************************************************************************

So the behavior of K infinite (and of course, of the isotopic vector composition in time) with photon transport is very non-physical. I attached 3 pictures where I actually compared K inf., U235 and Pu239 for the first 20 burnup steps (last step is about 27 MWd/KgU). I executed the depletion module, both with neutron-photon coupling and also when assuming a fix Q-value (i.e. local edep ). You can see that the fix Q value gives a qualitative physical behavior, while for the neutron-photon case is quite non-sense for the K inf. case. I am just burning at constant power for different batches of days a fresh UOX pin; therefore, the K inf. should decrease with time as the isotopic vector builds-up and the fuel changes. If you observe the behavior of Pu239, for the photon case there is a sharp build up from the beginning (at 27 MWd/KgU, there is already about 4 times more Pu239 than the one from the Q-fixed value case). I also want to add that for the Q-fixed value case, I already did a complete benchmark vs. SERPENT2 (assuming only local energy deposition) by employing the exact same Q values for both codes (this is why in my past input I sent you, you can see a dictionary of fixed Q values based on the SERPENT2 default ones). I have to say that the results of such benchmark are literally the same. At the end of irradiation (after 33 steps and a burnup of 60 MWd/KgU) the difference in K inf. is only of 8 pcm between both codes.

After all, I hope this is interesting to you. I just would like to help verifying this new capability of OpenMC, hoping we could find some answers to this effect. Thank you for your attention.

Augusto

On Wednesday, June 24, 2020 at 11:32:33 PM UTC+2, Paul Romano wrote:

Hi Augusto -- thanks for your persistence. This is indeed another bug; I've just submitted a fix for it and confirmed that it works for your model (thanks for sharing). Hopefully the fix will hit the develop branch soon.

Best,

Paul

To view this discussion on the web visit https://groups.google.com/d/msgid/openmc-users/33e8c0a9-469b-414e-a9db-5d965dd2a4bfo%40googlegroups.com.

[Paul Romano]

Hi Augusto,

Thanks for reporting this. I have observed the same issue and have some fixes underway that I will be sending a pull request for soon. I'll let you know when I have a branch ready to test if you want to try out your problem with a proposed fix.

Best,

Paul

To unsubscribe from this group and stop receiving emails from it, send an email to openmc-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openmc-users/19f3eed9-5105-4d88-b73e-0f8abc325cc6o%40googlegroups.com.