Is particle lifetime tracked?

Hi,
Looking at the code it appears that currently there is no time dependence and that particles don’t keep track of the time since the start of the history is this correct?
Specifically thinking of fixed source problems.

Hi @slilley and welcome to the forum! You are correct that we don’t actually keep track of time currently. I know some people have added this in developmental branches but it has never made it back to the main branch of OpenMC. It would be a pretty easy addition though. Is this something of interest to you?

Hi,

Yes, Currently looking at options for simulating pulsed sources for areas such as pulsed neutron die away experiments using a DD or DT generator, and detector development
If you can point me to the relevant branches i can look at, that would be very helpful

Hi @slilley. I put together an initial cut at an implementation for a time filter (along with tracking time for particles). I’ve only done some very light testing to make sure it passes a few sanity checks, but nothing very rigorous. If you want to try it out and let me know things go, that would be much appreciated.

To use the time filter, there is a new TimeFilter class that fundamentally behaves like EnergyFilter. You give it a list of times and it creates bins for each pair of values in the list. The units are specified in seconds.

Many thanks @paulromano, I will give it a go on a few test cases. A quick look through the commit makes me wonder if time also needs to be passed to the create secondary particle function. I’m not certain but I think secondaries will be created at time 0.

@slilley Yes, you’re absolutely right. I’ve just added some changes to my time-filter branch that should propagate time to secondary particles.

Hi @paulromano , I did a quick test on my project with this time-filter branch.
I am not sure whether I did any mistakes or not, but it seems that the problem still exist. The clock for secondary, tertiary, etc particles are still being restarted.

Could you please take a look on my notebook? I’ve sent my notebook to your pm.

edit2: add tag

@arief.rahman Thanks for the test case. Your suspicion was correct – fission neutrons did have their clock reset. I’ve now fixed that on my time-filter branch, so in your test case you should see no scores below 0.0001 s as expected.

@paulromano thank you for the time filter branch & apologies it has taken a while to look at this in more detail with @bakingbad,
In a simple vacuum only model with scoring current with a surface filter and time filter a set distance from a monoenergetic monodirectional source the result is clearly not correct with non-zero results in all time bins. A check using an energy filter correctly shows all the particles with the same energy. If however we split the model to have a second thin cell at the edge just before the surface tally then the time filter result looks a lot closer to what it should be.
My thoughts are:

  • As looking in the code I think the values are averaged over each time bin since the last update value/(n_bins in range t -t_last) which might be right for flux in cell tally (although i’m not certain that is right) it is not right for a surface tally. I think for surface tallies it should just be the particle time as it crosses the surface (assuming the surface crossing event is processed and the particle time updated before the tally is scored)

@bakingbad can supply a couple of test inputs demonstrating the issue if needed

.thanks so much for all your help

@slilley Many thanks to you and @bakingbad for testing this out and providing feedback! You’re absolutely right – as written, it is designed for a volumetric tally but not for a surface tally. I’ll have to think about how to handle these two situations and will post an update here if/when I have something new ready to test that accounts for surface tallies.

I just opened a pull request for this feature (surface current issue has been fixed):