Bugs in update 2.1.30

Report all good and bad behavior here
User avatar
Jaakko Leppänen
Site Admin
Posts: 2387
Joined: Thu Mar 18, 2010 10:43 pm
Security question 2: 0
Location: Espoo, Finland
Contact:

Bugs in update 2.1.30

Post by Jaakko Leppänen » Fri Feb 16, 2018 1:10 pm

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.
- Jaakko

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

Re: Bugs in update 2.1.30

Post by Jaakko Leppänen » Fri Feb 16, 2018 1:12 pm

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
- Jaakko

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

Re: Bugs in update 2.1.30

Post by Jaakko Leppänen » Fri Feb 16, 2018 1:17 pm

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;
  }
- Jaakko

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

Re: Bugs in update 2.1.30

Post by Jaakko Leppänen » Fri Feb 16, 2018 1:21 pm

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;
}
- Jaakko

Diego
Posts: 73
Joined: Wed Jun 01, 2011 8:49 pm

Re: Bugs in update 2.1.30

Post by Diego » Wed Feb 21, 2018 12:37 pm

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

Toni Kaltiaisenaho
Posts: 11
Joined: Sat Jun 27, 2015 3:31 pm
Security question 1: No
Security question 2: 92

Re: Bugs in update 2.1.30

Post by Toni Kaltiaisenaho » Wed Feb 21, 2018 5:10 pm

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.

Diego
Posts: 73
Joined: Wed Jun 01, 2011 8:49 pm

Re: Bugs in update 2.1.30

Post by Diego » Fri Feb 23, 2018 7:04 pm

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

Toni Kaltiaisenaho
Posts: 11
Joined: Sat Jun 27, 2015 3:31 pm
Security question 1: No
Security question 2: 92

Re: Bugs in update 2.1.30

Post by Toni Kaltiaisenaho » Tue Feb 27, 2018 3:16 pm

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.

Diego
Posts: 73
Joined: Wed Jun 01, 2011 8:49 pm

Re: Bugs in update 2.1.30

Post by Diego » Wed Feb 28, 2018 11:20 am

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

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

Re: Bugs in update 2.1.30

Post by Ville Valtavirta » Tue Apr 17, 2018 6:25 pm

An indexing bug in detectoroutput.c has been identified: http://ttuki.vtt.fi/serpent/viewtopic.php?f=25&t=2877

-Ville

Post Reply