Question regarding hex-y detector lattice

Report all good and bad behavior here
Post Reply
Diego
Posts: 73
Joined: Wed Jun 01, 2011 8:49 pm

Question regarding hex-y detector lattice

Post by Diego » Tue Jan 15, 2019 4:41 pm

Dear colleagues;
I have a simple question related to the hex-y lattices. I'm dealing with a 3D hex-y FA (VVER type) which has some positions with BP, as you can see in the following image:
30AV5-plot_geom1.png
30AV5-plot_geom1.png (121.67 KiB) Viewed 1470 times
For that geometry I would like to get pin-by-pin results for an axial slice. I checked the forum and WikiSerpent and I decided to use a power det as:

Code: Select all

det 3 dr -8 void dh 3 0 0 1.275 23 23 100 120 1 % 1 axial zone
When I check the _det.m output everything looks OK, where the results are as:

Code: Select all

DET3 = [
    1    1    1    1    1    1    1    1    1    1  0.00000E+00 0.00000 
    2    1    1    1    1    1    1    1    1    2  0.00000E+00 0.00000 
  .....
   35    1    1    1    1    1    1    1    2   12  2.97954E+03 0.01253 
   36    1    1    1    1    1    1    1    2   13  3.05876E+03 0.01240
...]

DET3COORD = [
-1.214601E+01 -2.103750E+01
-1.104182E+01 -2.040000E+01
...
0.000000E+00 -1.275000E+01
1.104182E+00 -1.211250E+01
...]


So in that point I suppose that the coordinates represent the x,y position as listed in the detector output (i.e. first x increases, then y). But I realized when I plotted the results that the indexing in the DET3 = [] vector has the x-y axis are interchanged (f.e. the position 2, --> 2 1 1 1 1 1 1 1 1 2 0.00000E+00 0.00000 should be the 24th position).
So basically if I plot the results directly I get a "reflected" geometry (see the inner BP ring):
incorrect.png
incorrect.png (210.18 KiB) Viewed 1470 times

But if I correct the order of the detector output considering that the x and y axis are interchanged (but maintaining the DET3COORD vector) as:

Code: Select all

k=0;
for i=1:23
for j=1:23
k++;
z(k)=DET3(i+(j-1)*23,11);
endfor
endfor 
Then I plot and I can get the expected result:
correct.png
correct.png (210.83 KiB) Viewed 1470 times

I'm missing something? Or this is on purpose? I know that for the hex-y lattice definition the x-y axes are interchanged, but I was not expecting that in the output (Maybe some clarification in the Wiki is enough)
Best,
Diego

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

Re: Question regarding hex-y detector lattice

Post by Ville Valtavirta » Wed Jan 16, 2019 11:52 am

Hi Diego,

based on some investigation, I think the X,Y -coordinates for the different bins in a hexagonal lattice detector are output incorrectly in the detector output file.

Looking at lines 320-322 in findlatticeregion.c the index of a hexagonal lattice element is calculated as

Code: Select all

	/* Index to lattice element */
	
	idx = i + (long)(nx/2.0) + (j + (long)(ny/2.0))*nx;
where index i runs fastest and index j runs slowest.

When the detector coordinates are printed in detectoroutput.c at lines 660-685 we have

Code: Select all

                  /* Loop over lattice */

                  i = -(long)((double)n0/2.0);
                  for (n = 0; n < n0; n++)
                    {
                      j = -(long)((double)n1/2.0);
                      for (m = 0; m < n1; m++)
                        {
                          if ((long)RDB[ptr + MESH_TYPE] == MESH_TYPE_HEXX)
                            {
                              x = x0 + (i + COS60*j)*pitch;
                              y = y0 + j*SIN60*pitch;
                            }
                          else if ((long)RDB[ptr + MESH_TYPE] == MESH_TYPE_HEXY)
                            {
                              x = x0 + j*SIN60*pitch;
                              y = y0 + (i + COS60*j)*pitch;
                            }

                          j++;

                          fprintf(fp, "%E %E\n", x, y);
                        }
                      i++;
                    }
where index j runs fastest and i runs slowest. Switching the order of indexing in the output routine to

Code: Select all

                  /* Loop over lattice */

                  j = -(long)((double)n1/2.0);
                  for (n = 0; n < n1; n++)
                    {
                      i = -(long)((double)n0/2.0);
                      for (m = 0; m < n0; m++)
                        {
                          if ((long)RDB[ptr + MESH_TYPE] == MESH_TYPE_HEXX)
                            {
                              x = x0 + (i + COS60*j)*pitch;
                              y = y0 + j*SIN60*pitch;
                            }
                          else if ((long)RDB[ptr + MESH_TYPE] == MESH_TYPE_HEXY)
                            {
                              x = x0 + j*SIN60*pitch;
                              y = y0 + (i + COS60*j)*pitch;
                            }

                          i++;

                          fprintf(fp, "%E %E\n", x, y);
                        }
                      j++;
                    }
seems to solve the issue for both hexx and hexy type lattices.

-Ville

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

Re: Question regarding hex-y detector lattice

Post by Diego » Wed Jan 16, 2019 12:30 pm

Thanks Ville!
Diego

nico
Posts: 23
Joined: Wed Feb 28, 2018 1:57 pm
Security question 1: No
Security question 2: 93

Re: Question regarding hex-y detector lattice

Post by nico » Mon Mar 30, 2020 1:34 pm

Dear Ville,
I suspect that there is something wrong in the way Serpent associates the tallies to the assembly numbers.

Checking the results of the attached results, you can see that the first assembly with non-zero power in the "_core0.m" file is the 243, while the first non-zero power in the "_det0.m" file is the number 210.
Counting the assemblies starting from the top-left corner of the lattice matrix and going down by rows I am okay with the "_core0.m" numeration, that seems correct.
As regards the "_det0.m" output, instead, I think that Serpent actually skips one row in the matrix...This is confirmed also if you look at output posted under the post "exagonal mesh detector (dh)" (viewtopic.php?f=15&t=3143&p=9582&hilit= ... ctor#p9582).
In this case, the non-zero flux is at position 13, but that is true only if you skip the first void row!

Hope that you could help me to understand why the two output numeration is not consistent
thank you so much
Nicolo'
Attachments
dethex_results.zip
(163.31 KiB) Downloaded 72 times

Post Reply