Error while running with new CMFD tally

[bhermanmit]

I got the following error after running CMFD with the new diffusion coefficient tally:

ERROR: Multiple interpolation regions not supported while attempting to sample continuous tabular distribution. Batch: 119 Generation: 1 Particle: 1909272 Location: -9.9946E+01 -8.9696E+01 2.2091E+02 Direction: -8.5611E-01 3.8309E-01 3.4686E-01

I put some flags around to make sure that it is getting out of the CMFD routines before this occurs and it does. My run gets to the 118th batch. This error is not thrown if I run my base case without CMFD or when I am using CMFD without the new diffusion coefficients. Let me know how I can help flush this out.

[paulromano]

That's very odd -- none of the ACE data we have has law 4 with multiple interpolation regions to my knowledge, so that error shouldn't get hit. That might mean you're overwriting memory somewhere. Without knowing what you changed though, it's hard to say anything. Have you tried compiling with DEBUG on? Write some diagnostic output right before that error gets hit?

[bhermanmit]

I went ahead and put in the new Tally structure for the diffusion coefficient. While testing in debug it kept failing in routine get_mesh_indices during tracklength tallying. Although my CMFD tallies are currently analog, I was tallying the pin-wise fission source with the user tally interface. I have a 2-D mesh there and that was raising an except due to this math statement:

! Find particle in mesh
 ijk = ceiling((xyz - m % lower_left)/m % width)

xyz will have a length of 3 while the mesh has a length of 2.

I switched to a 3-D and things seem to be running in DEBUG for a small case. I will rerun the big case overnight in DEBUG mode.

[paulromano]

So you're saying a tally that has a mesh filter with a 2D mesh fails?

[bhermanmit]

Yes below is the tally file and the error:

<?xml version="1.0" encoding="UTF-8"?>
<tallies>

  <tally id="1">
    <filter type="mesh" bins="1"/>
    <scores>nu-fission</scores>
  </tally>

  <mesh id="1">
    <type>rectangular</type>
    <lower_left>-161.2773 -161.2773</lower_left>
    <upper_right>161.2773 161.2773</upper_right>
    <dimension>255 255</dimension>
  </mesh>

</tallies>

forrtl: severe (408): fort: (2): Subscript #1 of the array WIDTH has value 3 which is greater than the upper bound of 2

Image              PC                Routine            Line        Source
libirc.so          00002B523DC02A7A  Unknown               Unknown  Unknown
libirc.so          00002B523DC01576  Unknown               Unknown  Unknown
libifcore.so.5     00002B523CD0E80C  Unknown               Unknown  Unknown
libifcore.so.5     00002B523CC80DB2  Unknown               Unknown  Unknown
libifcore.so.5     00002B523CC81333  Unknown               Unknown  Unknown
openmc             0000000000797B26  mesh_mp_get_mesh_          82  mesh.F90
openmc             00000000008EC373  tally_mp_score_tl        1000  tally.F90
openmc             00000000008D2D8A  tally_mp_score_tr         475  tally.F90
openmc             0000000000821509  physics_mp_transp         104  physics.F90
openmc             00000000005F0E49  eigenvalue_mp_run          83  eigenvalue.F90
openmc             0000000000792D3B  MAIN__                     21  main.F90
openmc             000000000040A01C  Unknown               Unknown  Unknown
libc.so.6          000000334601D994  Unknown               Unknown  Unknown
openmc             0000000000409F29  Unknown               Unknown  Unknown

[paulromano]

Ok, are you still having the problem related to the new diffusion coefficient tally? If so, the problem with 2D mesh tallies should have it's own issue assigned.

[bhermanmit]

Closing this issue, because it does not need to be address. If it occurs again, I will write a better explanation.