GROUPR processing for TNSL data: possible infinite loop?

[mattooca]

I'm trying to process the ENDF/B-VIII.0 tsl-HinH20 evaluation using THERMR and GROUPR (want to compare with FUDGE results). Just using 300 K data for now. THERMR finished in about a minute, but GROUPR ran for about 18 hours before I killed it. Is that expected? This is the first time I've tried to generate transfer matrices from TNSL files.

Some details:

• The 18 hour test was done with NJOY2016.44. I updated to 2016.49 this morning and tried again. So far GROUPR has been running for ~2 hours using the new version.

• Input file is attached xnjoy.input.txt. Before running this, I made tape20 a symlink to n-001_H_001.endf and tape21 a symlink to tsl-HinH20.endf (both from ENDF/B-VIII).

BTW, both iform=0 and iform=1 work again in THERMR, thanks for fixing that! Interesting to note that the MT=221 cross section changes a bit (generally in the 3rd significant digit or lower) depending on which iform is used.

Cheers, Caleb

[whaeck]

Oh goodie. Another GROUPR issue :-(

I'll have a look as soon as I can.

[mattooca]

Oops, looks like user error was partly responsible. I passed in the original file 7 (tsl-HinH2O.endf) as the 'nendf' tape and used the TNSL MAT (1) for matb. I just tried using the 'normal' neutron evaluation (n-001_H_001.endf) for nendf and MAT 125 for matb, and was able to finish processing.

With my original input file, seems like errorr should have detected that the requested MAT was missing from the pendf tape and aborted with an error message. Instead it got stuck in a loop somewhere.

[whaeck]

Sorry for replying so late on this. Having seen that it was an actual input error, I neglected checking why you go into a loop. I have tried the input and I indeed go into an infinite loop.

[whaeck]

This is a fun one, and will probably only happen when the MAT number you are looking for is 1 ;-)

This is what happens:

The first few lines of tape25 look like this:

pendf tape for MAT=   125 evaluation                                 1 0  0    0
 1.001000+3 9.991673-1          2          0          0          0 125 1451    1
 0.000000+0 0.000000+0          0          0          0          6 125 1451    2

We need to find MAT1, MF1, MT451 in groupr (line 471) so we call findf (from endf.f90). When we call this function, the file position is at the end of the first line (or the beginning of the second line if you want). The first thing that happens in findf, is that the function will read a line and determine the current MAT, MF, MT, being MAT125, MF1, MT451 which is not the one we are looking for.

findf then checks how to get to the proper material and assumes that everythong is sorted by MAT number. This happens between lines 1502 and 1507 of endf.f90. The function sees that the desired material (MAT1) is smaller than the one we found (MAT125) so we have to go BACK. This then directs us to label 200 in the findf function were we call skiprz to go back 2 lines to the last line of a hypothetical previous section. skiprz uses backspace to do this. Now, because we are at the beginning of the file, the second call to backspace places us at the beginning of the file. Additional calls to backspace would not change the position in the file any further.

We again read where we are: MAT1, MF0, MT0 because the tape label on the first line says so. And that is the material we need (MAT1) so we now check the MF and MT number but those are not the ones we were looking for so we end up at label 200 again.

And that's where we try to go back 2 lines again, ending up at the beginning of the file once more. This initiates the infinite loop.

[whaeck]

Branch #127 contains a fix for this issue as well.

[kahlerac]

All, The tape number cannot be the same as the main number. This is a long known NJOY restriction. Skip

On Fri, Apr 12, 2019, 9:19 AM Wim Haeck notifications@github.com wrote:

This is a fun one, and will probably only happen when the MAT number you are looking for is 1 ;-)

This is what happens:

The first few lines of tape25 look like this:

pendf tape for MAT= 125 evaluation 1 0 0 0 1.001000+3 9.991673-1 2 0 0 0 125 1451 1 0.000000+0 0.000000+0 0 0 0 6 125 1451 2

We need to find MAT1, MF1, MT451 in groupr (line 471) so we call findf (from endf.f90). When we call this function, the file position is at the end of the first line (or the beginning of the second line if you want). The first thing that happens in findf, is that the function will read a line and determine the current MAT, MF, MT, being MAT125, MF1, MT451 which is not the one we are looking for.

findf then checks how to get to the proper material and assumes that everythong is sorted by MAT number. This happens between lines 1502 and 1507 of endf.f90. The function sees that the desired material (MAT1) is smaller than the one we found (MAT125) so we have to go BACK. This then directs us to label 200 in the findf function were we call skiprz to go back 2 lines to the last line of a hypothetical previous section. skiprz uses backspace to do this. Now, because we are at the beginning of the file, the second call to backspace places us at the beginning of the file. Additional calls to backspace would not change the position in the file any further.

We again read where we are: MAT1, MF0, MT0 because the tape label on the first line says so. And that is the material we need (MAT1) so we now check the MF and MT number but those are not the ones we were looking for so we end up at label 200 again.

And that's where we try to go back 2 lines again, ending up at the beginning of the file once more. This initiates the infinite loop.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/njoy/NJOY2016/issues/123#issuecomment-482592061, or mute the thread https://github.com/notifications/unsubscribe-auth/AQ6USec8JrtlNV9hj_m8drcHbVykyGD2ks5vgJXigaJpZM4bkIZf .

[whaeck]

The fix in branch #127 for this issue was taken out because the fix was not standard fortran compliant (it used specific compiler function to achieve its goal).

[jlconlin]

I'm not sure what non-standard fortran was removed. Can you please show?

[whaeck]

ftell is a non standard fortran function available in gcc, but not necessarily for other compilers:

      if (ftell(abs(ntape)).eq.0) go to 400

Austin and I tried to work around it but failed to do so.