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

"use_exp_form = true" flag often causes simulations to fail #121

Open
smpark7 opened this issue Aug 12, 2020 · 2 comments
Open

"use_exp_form = true" flag often causes simulations to fail #121

smpark7 opened this issue Aug 12, 2020 · 2 comments

Comments

@smpark7
Copy link
Collaborator

smpark7 commented Aug 12, 2020

The use_exp_form = true flag allows users to track neutron flux values as exponent values instead of raw values (e.g. e^10 -> 10). Refer to moltres/src/base/ScalarTransportBase.C for the source code.

However, this flag requires careful use because it easily triggers the DIVERGED_FNORM_NAN error on nonlinear solve iterations. The error message does not indicate that use_exp_form is responsible for the failed solve.

I suspect that it triggers the error because Moltres tries to evaluate exp(x) and the value can easily exceed the maximum representable float/double.

This issue is more of a PSA for future users who encounter the DIVERGED_FNORM_NAN with this flag, which is true by default.

@gridley
Copy link
Collaborator

gridley commented Aug 17, 2020

I think deprecating use_exp_form would be worth considering. It adds a pretty large expense to have to compute logarithms/exponentials at each quadrature point. In fact, I believe it would speed moltres up fairly to simply eliminate the computeQpConcentration. I can't think of any problem where this approach is actually necessary. Maybe there is some problem where this is required in plasma problems, but there are no neutronics problems documenting this in the literature which require this approach. Its accuracy is also debatable considering that discretization error is much larger than roundoff error in any case Moltres runs.

@smpark7
Copy link
Collaborator Author

smpark7 commented Aug 20, 2020

Hi @gridley . Yea I also can't think of cases when computeQpConcentration would be useful. MOOSE provides better alternatives for scaling. I'll probably make a PR for this when I have the time.

@smpark7 smpark7 self-assigned this Aug 20, 2020
@katyhuff katyhuff added this to new in Moltres via automation Sep 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Moltres
  
new
Development

No branches or pull requests

2 participants