Update on delayed/prompt neutrons detectors

Questions and discussion about applications, input, output and general user topics
mascovale
Posts: 23
Joined: Sat Nov 18, 2017 12:45 am
Security question 1: No
Security question 2: 72
Location: Virginia Tech Transport Theory Group (VT3G), Virginia Tech, Falls Church, VA

Re: Update on delayed/prompt neutrons detectors

Post by mascovale » Fri Apr 13, 2018 3:20 am

Hi Ville,

I haven't moved on with implementing the changes within[\i] Serpent as you kindly explained. On a different note, I have 3 related questions:
  1. ANA_KEFF results in <input>_res.m: in particular, I read that the 3rd and 4th values refer to prompt neutrons only; while the 5th and 6th refer to delayed. Can you expand on that? Is the 3rd value k-prompt? The numbers doesn't always add up to the total number.
  2. For whatever reason, when I run the calculation using the -mpi option, I get wrong results for the prompt and delayed values. In particular, these values are approximately 1/N_proc times the actual value, where N_proc is the number of processors I used. (I am attaching the input, _res.m, and runscript files that I used)
  3. In a very old post (see this post), it was stated that "set delnu 0" doesn't actually stop tallying delayed neutrons but makes the code handle them as prompt. I assume this has since been updated, and the detectors (when I set delnu 0) are only tallying prompt neutrons. I would also assume so based on our previous interactions in this thread. Is that correct?


Thanks again for the help you are providing!
Attachments
prb.zip
"prb" input file; "prb_res.m" output file; "serpent.sh" bash script to submit Serpent job using mpi
(10.49 KiB) Downloaded 118 times

User avatar
Jaakko Leppänen
Site Admin
Posts: 2446
Joined: Thu Mar 18, 2010 10:43 pm
Security question 2: 0
Location: Espoo, Finland
Contact:

Re: Update on delayed/prompt neutrons detectors

Post by Jaakko Leppänen » Fri Apr 13, 2018 11:57 am

You are right about ANA_KEFF. The analog estimator is calculated simply as the ratio between the number of total/prompt/delayed fission neutrons to source neutrons. Since the values are averaged over all generations, you cannot expect the sum of prompt and delayed components to exactly match the total. Are the differences still within the statistics?

The prompt and delayed ANA_KEFF are not scored in the same subroutine as the total, so the adjustment in population size in MPI mode is probably not taken into account. Try adding divider mpitasks on lines 748 and 753:

Code: Select all

      val = BufVal(ptr, 1)/RDB[DATA_CRIT_POP]/mpitasks;
Setting delnu 0 switches delayed neutron emission off completely.
- Jaakko

mascovale
Posts: 23
Joined: Sat Nov 18, 2017 12:45 am
Security question 1: No
Security question 2: 72
Location: Virginia Tech Transport Theory Group (VT3G), Virginia Tech, Falls Church, VA

Re: Update on delayed/prompt neutrons detectors

Post by mascovale » Tue May 22, 2018 4:34 am

Dear Ville (and Jaakko),

I wanted to give you an update on our previous discussion for having Serpent tally delayed neutrons ONLY (as described in your answer to this post on April 11). This is the list of modifications I have added to the code:

I have added a new variable, called DATA_TALLY_DEL: if it is set to 0, nothing happens (default); if it's set to 1 the delayed neutrons tally only option is activated.

I have added the following line to locations.h:

Code: Select all

/* Delayed-only tally option */
#define DATA_TALLY_DEL                 1069
Initialization in file initdata.c:

Code: Select all

/* Delayed-only tally flag */
WDB[DATA_TALLY_DEL] = 0.0;
And finally the following code block in readinput.c:

Code: Select all

    else if (!strcasecmp(params[j], "deltal"))
      {
        /***** Sample delayed neutrons *********************************/

        /* Copy parameter name */

        strcpy (pname, params[j]);

        k = j + 1;

        /* Mode */

        if (k < np)
    WDB[DATA_TALLY_DEL] =
      TestParam(pname, fname, line, params[k++], PTYPE_LOGICAL);

        /***************************************************************/
      }
This new variable is used in interpolatenubar.c. First of all, I am circumventing the "return" if-statements in the following way: the delayed neutron subtraction code block is executed if DATA_USE_DELNU = 0 or when DATA_TALLY_DEL = 1 (first if); if no data is found for delayed neutrons and DATA_TALLY_DEL =1, then values are = 0.0 (second if). Here is the code:

Code: Select all

  /***** Subtract delayed nubar data *****************************************/

  /* Check flag - NOTE (vm): if DATA_TALLY_DEL is equal to 1 it does not return, rather substitutes the values*/

  if (((long)RDB[DATA_USE_DELNU] != NO) && ((long)RDB[DATA_TALLY_DEL] != YES))
    return;

  /* Get pointer to delayed nubar data */

  if ((loc0 = (long)RDB[rea + REACTION_PTR_DNUBAR]) < VALID_PTR)
    {
      if ((long)RDB[DATA_TALLY_DEL] == 1) {

        /* If no delayed nubar data is available when tallying delayed neutrons only, set to 0 */

        for (n = 0; n < ne; n++) {
          nubar [n] = 0;
        }
      }
      return;
    }
If data is present, Serpent checks whether the data file is given as polynomial or tabular. If the data is given as polynomial, then the values are calculated as follows:

Code: Select all

    if (((long)RDB[DATA_TALLY_DEL] == 0) || ((long)RDB[DATA_USE_DELNU] == 0))
    {
    /* Initial value */

    nubar[n] = nubar[n] - RDB[ptr];
    x = E[n];

    /* Loop over coefficients */

    for (m = 1; m < np; m++)
      {
        nubar[n] = nubar[n] - RDB[ptr + m]*x;
        x = x*E[n];
      }

    /* Check value */

    CheckValue(FUNCTION_NAME, "nubar", "", nubar[n], 1.5, 60.0);
    }
    else
    {

    /* THIS OPTION HAS BEEN ADDED TO ONLY TALLY DELAYED NEUTRONS (vm) */

    /* Initial value */

    nubar[n] = RDB[ptr];
    x = E[n];

    /* Loop over coefficients */

    for (m = 1; m < np; m++)
      {
        nubar[n] = nubar[n] + RDB[ptr + m]*x;
        x = x*E[n];
      }

    /* Check value */

    CheckValue(FUNCTION_NAME, "nubar", "", nubar[n], 0.015, 0.6);
    }
  }
Otherwise, if they are tabular:

Code: Select all

      {
        /* Check if only DELAYED neutrons have to be tallied (vm)*/
        if (((long)RDB[DATA_TALLY_DEL] == 0) || ((long)RDB[DATA_USE_DELNU] == 0)) {
          nubar[n] = nubar[n] - dnubar[n];

          /* Check value */

          CheckValue(FUNCTION_NAME, "nubar", "", nubar[n], 1.5, 60.0);

        } else if ((long)RDB[DATA_TALLY_DEL] == 1) {
          nubar[n] = dnubar[n];

          /* Check value */

          CheckValue(FUNCTION_NAME, "nubar", "", nubar[n], 0.015, 0.60);

        }

      }
To tally delayed neutrons with these modifications, I then use a dr -7 detector, as opposed to the dr -100 that I was using with the other approach that I tried.

I am currently testing this procedure. So far I run a k-calculation and got a total production of delayed neutrons compatible with the one dr -100 method. The two results weren't within statistical uncertainty, however for the detector function tallying approach I had used a different library. The two results were within 0.8% of each other while the statistical uncertainty of the value given by Serpent is 0.005%. I am tempted to think that the 0.8% comes from the different libraries employed.

I'd appreciate any feedback you can provide.
Thanks a lot for the help you have provided!

Ville Valtavirta
Posts: 536
Joined: Fri Sep 07, 2012 1:43 pm
Security question 1: No
Security question 2: 92

Re: Update on delayed/prompt neutrons detectors

Post by Ville Valtavirta » Wed May 23, 2018 6:12 pm

I think those changes should do the trick, i.e. only use the delayed nubar for the neutron physics. The small difference may very well be from the libraries.

For future source code adventures: Everything in RDB/WDB is initialized to zero in the beginning of the execution so no need to initialize zero-values in initdata.c.

-Ville

mascovale
Posts: 23
Joined: Sat Nov 18, 2017 12:45 am
Security question 1: No
Security question 2: 72
Location: Virginia Tech Transport Theory Group (VT3G), Virginia Tech, Falls Church, VA

Re: Update on delayed/prompt neutrons detectors

Post by mascovale » Thu May 24, 2018 12:55 am

Thanks a lot!
Valerio Mascolino
PhD Candidate
Virginia Tech

takezawa
Posts: 4
Joined: Wed May 26, 2021 5:12 pm
Security question 1: No
Security question 2: 7

Re: Update on delayed/prompt neutrons detectors

Post by takezawa » Fri May 28, 2021 5:39 am

Hi all,

I have been interested in tallying fission rate by looking at which source neutron (prompt or delayed neutron) caused the fission, where the source neutron was born, and when the fission was induced from the birth of the source neutron. Calculation mode is criticality calculation. This calculation is similar to fission matrix calculation, however it is necessary to use di option in det card for measuring the fission-to-fission time.

Currently, I have two potential approaches for this purpose.
First one will be repeating single-cycle criticality calculations (or fixed source calculations) by separately setting initial prompt or delayed neutron sources after obtaining a fundamental source distribution by preceding criticality calculation for the problem reactor conditions. This is a simple approach, but needs to repeat the number of combinations between source regions and at least two types of source neutrons.

Second one is to modify a source program of fission matrix calculation in order to reflect the fission-to-fission time. However, I am not sure how much modification works will be necessary for this approach.

It would be appreciated if you could share which approach is easier or any other idea for this purpose.


Best regards,
Hiroki
Ville Valtavirta wrote:
Fri Apr 06, 2018 2:33 pm
Thank you,

that's quite clear. Do you also need to distinguish between detector responses caused by prompt and delayed neutrons? Or only between the prompt and delayed neutrons produced?

-Ville
Hiroki Takezawa
Tokyo Institute of Technology

Ana Jambrina
Posts: 619
Joined: Tue May 26, 2020 5:32 pm
Security question 1: No
Security question 2: 7

Re: Update on delayed/prompt neutrons detectors

Post by Ana Jambrina » Fri May 28, 2021 2:59 pm

The transient fission matrix-based Monte Carlo method described by Laureau et al. (2015) might bring some light: https://doi.org/10.1016/j.anucene.2015.07.023.
- Ana

takezawa
Posts: 4
Joined: Wed May 26, 2021 5:12 pm
Security question 1: No
Security question 2: 7

Re: Update on delayed/prompt neutrons detectors

Post by takezawa » Mon Jun 14, 2021 12:12 pm

Thank you Ana for sharing a reference on transient fission matrix (TFM).

The authors firstly used MCNP5 for TFM calculation. Their first approach is essentially the same as my first option. Later, they modified Serpent2 for the same purpose: Blaise et al. (2019) https://doi.org/10.1016/j.anucene.2019.01.031. However, no detailed information is available on the modification.

So, my question is what modifications will be necessary for using "di" option with "set fmtx" card? The use of fmtx card with di option can calculate TFM faster than repeating single-cycle criticality calculations for the number of source cells.
Hiroki Takezawa
Tokyo Institute of Technology

Ana Jambrina
Posts: 619
Joined: Tue May 26, 2020 5:32 pm
Security question 1: No
Security question 2: 7

Re: Update on delayed/prompt neutrons detectors

Post by Ana Jambrina » Mon Jun 14, 2021 1:51 pm

To set a time discretisation when collecting data, as in the ‘di’ detectors, I would start by adding to the fission matrix mesh structure a time binning structure. From there, differentiate neutrons from their birth (prompt and delayed) and production (prompt and delayed).
- Ana

takezawa
Posts: 4
Joined: Wed May 26, 2021 5:12 pm
Security question 1: No
Security question 2: 7

Re: Update on delayed/prompt neutrons detectors

Post by takezawa » Tue Jun 15, 2021 1:02 pm

Thank you Ana.
After adding a time binning structure to a fission matrix, can I use a default time variable in Serpent in order to obtain neutron flight time between source and secondary fission points? To do so, do I need to define multiple detector cards with di option to all cells which include fissile nuclides?
Hiroki Takezawa
Tokyo Institute of Technology

Post Reply