Page 1 of 2

Bugs in update 2.1.30

Posted: Fri Feb 16, 2018 1:10 pm
by Jaakko Leppänen
Serpent 2.1.30 was distributed on February 14, 2018. The update included considerable changes in the source code, merged from three different development versions. Consequently, there are a number new bugs which have been discovered since the update was released. Quick fixes are posted on this thread.

Re: Bugs in update 2.1.30

Posted: Fri Feb 16, 2018 1:12 pm
by Jaakko Leppänen
There is an uninitialized variable in processcompton.c, which may cause the calculation to crash in photon transport mode. The problem can be fixed by adding:

Code: Select all

Npz = 0;
on line 510 of processcompton.c

Re: Bugs in update 2.1.30

Posted: Fri Feb 16, 2018 1:17 pm
by Jaakko Leppänen
There is a bug in readrestartfile.c, which may result in negative atomic densities in some calculations involving restart files. This can be fixed by changing lines 359-361 of readrestartfile.c from:

Code: Select all

if (RDB[mat + MATERIAL_RESTART_ADENS_F] == 0.0)
  WDB[mat + MATERIAL_RESTART_ADENS_F] = 
	RDB[mat + MATERIAL_ADENS]/adens;
to:

Code: Select all

if (RDB[mat + MATERIAL_RESTART_ADENS_F] == 0.0)
  {
   if (RDB[mat + MATERIAL_ADENS] < 0.0)
      WDB[mat + MATERIAL_RESTART_ADENS_F] = -RDB[mat + MATERIAL_ADENS]/mdens;
   else
      WDB[mat + MATERIAL_RESTART_ADENS_F] = RDB[mat + MATERIAL_ADENS]/adens;
  }

Re: Bugs in update 2.1.30

Posted: Fri Feb 16, 2018 1:21 pm
by Jaakko Leppänen
Generation of search mesh fails for some STL geometries. This can be fixed by changing lines 372-373 of addsearchmesh.c from:

Code: Select all

  
if ((long)RDB[msh + MESH_CONTENT_DATA_TYPE] == MESH_CONTENT_DATA_STL)
   WDB[loc2 + SEARCH_MESH_PTR_CELL_COUNT] = -1.0;
to:

Code: Select all

if ((long)RDB[msh + MESH_CONTENT_DATA_TYPE] == MESH_CONTENT_DATA_STL)
   WDB[loc2 + SEARCH_MESH_PTR_CELL_COUNT] = -1.0;
else if (((long)RDB[loc2 + SEARCH_MESH_PTR_CELL_COUNT] < VALID_PTR)
          && ((long)RDB[msh + MESH_CONTENT_DATA_TYPE] != MESH_CONTENT_DATA_TET))
{
   ptr = AllocPrivateData(1, PRIVA_ARRAY);
   WDB[loc2 + SEARCH_MESH_PTR_CELL_COUNT] = (double)ptr;
}

Re: Bugs in update 2.1.30

Posted: Wed Feb 21, 2018 12:37 pm
by Diego
Hi Jaakko,
I'm trying to run a coupled ng calculation with 2.1.30 (using set pop ... + ngamma 1 + set pdatadir + set acelib "neutron library " "photon library")
If I run with the original S2.1.30 version, compiled in hybrid mode (OMP + OMPI) and I get an strange error error:

Code: Select all

 *** Process received signal ***
 Signal: Segmentation fault (11)
 Signal code: Address not mapped (1)
Failing at address: (nil)
[ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0xf890)[0x7f8645a85890]
[ 1] sss2.1.30_intelOMPI[0x4074d6]
[ 2] sss2.1.30_intelOMPI[0x4efd8e]
[ 3] sss2.1.30_intelOMPI[0x537e74]
[ 4] sss2.1.30_intelOMPI[0x49437c]
 [ 5] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f86456ecb45]
[ 6] sss2.1.30_intelOMPI[0x403b29]
 *** End of error message ***
Segmentation fault

If I change processcompton.c in line 510 (Npz=0) an recompile, I also get an error :

Code: Select all

Fatal error in function ProcessComptonExtrapolation:

Incorrect Compton profile integral 5.000000000000E-01

Simulation aborted.
This happens both when running only sequential, only OMP or Hybrid modes.
I would appreciate any help! Thanks!
Diego

Re: Bugs in update 2.1.30

Posted: Wed Feb 21, 2018 5:10 pm
by Toni Kaltiaisenaho
Hi,

ProcessComptonExtrapolation() fails due to floating point precision. Please change the following lines

Code: Select all

  /* Check the integral between 0 and infinity (floating-point accuracy?) */
  if (I_end + Iextrap != 0.5)
    Die(FUNCTION_NAME, "Incorrect Compton profile integral %.12E",
        I_end + Iextrap);
to

Code: Select all

  /* Check the integral */
  if (I_end + Iextrap != 0.5) {

    if (fabs(I_end + Iextrap - 0.5) > 1.e-10) {
      Die(FUNCTION_NAME, "Incorrect Compton profile integral %.15E (error 1)",
          I_end + Iextrap);
    }
    else {
      /* Adjust the integral */
      Iextrap = fabs(I_end - 0.5);

      if (I_end + Iextrap != 0.5)
        Die(FUNCTION_NAME, "Incorrect Compton profile integral %.15E "
                           "(error 2)", I_end + Iextrap);
    }
  }
in the function ProcessComptonExtrapolation() in processcompton.c.

Re: Bugs in update 2.1.30

Posted: Fri Feb 23, 2018 7:04 pm
by Diego
Hi Toni,
Thank you! I've just updated the ProcessComptonExtrapolation() subroutine but now the code just get stuck on:

Code: Select all

  Processing response functions for photon dose rates...
I think it might be related with the amount of materials I'm dealing with (~1e5, using automatic division), as far as the code runs ok if avoid the division of depletion zones (i.e I get a to the point where "
(O1) (TMS) (XE) (N/P) (MPI=1) (OMP=5) (CE/LI) " is printed) .
Is there something such as maximum number of materials to be handled? Do you have any advice on this?
Thanks in advance,
Diego

Re: Bugs in update 2.1.30

Posted: Tue Feb 27, 2018 3:16 pm
by Toni Kaltiaisenaho
It seems that the function ProcessPhotonAtt can't handle large number of materials efficiently. This function processes the data needed for the photon response numbers -200 - -248. As a quick fix, you can comment out line 327 in processmaterials.c if you are not using these response functions:

Code: Select all

/* ProcessPhotonAtt(); */
You will also most likely encounter memory usage issues in the function ProcessTTB with such a high number of materials. The memory usage is about 0.9 GiB per 1000 materials. You can decrease the size of the electron stopping power grid from the default 200 to about 75:

Code: Select all

set elspn 75 
With this grid size, the memory usage is about 0.13 GiB per 1000 materials. The grid size determines the size of the thick-target bremsstrahlung energy matrices and other data which are used for sampling bremsstrahlung photons. I ran a couple of test cases with the grid sizes of 75 and 200, and I didn't find any significant differences in the bremsstrahlung spectrum below 10 MeV or so. I may add an automatic adjustment of the grid size if the number of materials is large in the future.

Re: Bugs in update 2.1.30

Posted: Wed Feb 28, 2018 11:20 am
by Diego
Thanks Toni!
BTW, as you said, the additional RAM memory was about ~110 GB for these 1e5 materials when NG coupled calculations are done (with default options).
Diego

Re: Bugs in update 2.1.30

Posted: Tue Apr 17, 2018 6:25 pm
by Ville Valtavirta
An indexing bug in detectoroutput.c has been identified: http://ttuki.vtt.fi/serpent/viewtopic.php?f=25&t=2877

-Ville