Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ACER doesn't find temperature when value is very high #222

Open
paulromano opened this issue Oct 28, 2021 · 5 comments
Open

ACER doesn't find temperature when value is very high #222

paulromano opened this issue Oct 28, 2021 · 5 comments

Comments

@paulromano
Copy link
Member

Broadening H2 from ENDF/B-VIII.0 to T=10,000,001 K results in strange error in ACER. Namely, with the following input:

reconr /
20 21
'ENDF/B-8.0 PENDF for   1-H -  2 '/
128 2/
0.001/ err
'ENDF/B-8.0:   1-H -  2 '/
'Processed by NJOY'/
0/

broadr /
20 21 22
128 1 0 0 0. /
0.001/ errthn
10000001.0
0/

acer /
20 22 0 23 24
1 0 1 .01 /
'ENDF/B-8.0:   1-H -  2  at 10000001.0'/
128 10000001.0
1 1/
/
stop

Running this with NJOY, I get:


 njoy 2016.65  xxAug21                                       10/27/21 22:10:55
 *****************************************************************************

 reconr...                                                                0.0s

 broadr...                                                                0.0s

 acer...                                                                  0.2s

 ***error in first***desired temperature not found.
 
STOP 77

I'm not sure what exactly it is that makes NJOY break. Other large temperatures (e.g., T=10,000,010 K) seem to work.

@whaeck
Copy link
Member

whaeck commented Nov 4, 2021

This is due to the ENDF precision while using ASCII ENDF files to exchange information between NJOY modules. Since we only have 6 digits after the decimal point, 10000001 get printed as 1.000000+7, leading to a difference of 1 K which fails the test in the first subroutine.

Switching to binary mode resolve this without any code changes, but I'm inclined to add a relative tolerance check on the temperature as well.

@whaeck
Copy link
Member

whaeck commented Nov 4, 2021

10000010 actually works because you can write this as 1.000001+7 in an ASCII ENDF file. Gotta love fixed precision.

@paulromano
Copy link
Member Author

@whaeck Is there anywhere one can find an up-to-date description of the ACE binary format? I do see that going to binary fixes this, but if you write an ASCII ACE file the precision is lost at the last step.

@whaeck
Copy link
Member

whaeck commented Nov 22, 2021

As far as I know, the binary ACE format is actually compiler dependent (and you need the same one for MCNP for it to read the file) - at least it was like that over 15 years ago. I could not get binary ACE files coming out of NJOY get accepted by different versions of MCNP(X).

We're actually looking into a new binary format for the data going into MCNP but that is still for out in the future.

@paulromano
Copy link
Member Author

Ok, that seems like a wise idea. Thanks for the clarification @whaeck!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants