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

perform only 1 residual calculation if solve_type=Linear #11760

Closed
WilkAndy opened this issue Jun 27, 2018 · 3 comments
Closed

perform only 1 residual calculation if solve_type=Linear #11760

WilkAndy opened this issue Jun 27, 2018 · 3 comments
Labels
C: Framework P: normal A defect affecting operation with a low possibility of significantly affects. T: task An enhancement to the software.

Comments

@WilkAndy
Copy link
Contributor

Rationale

Only 1 residual calculation per timestep is needed if solve_type=Linear.

Description

At the moment two residual calculations are performed every timestep. One for the first nonlinear residual (this is required), then PETSc does its linear solve, and then another, redundant, nonlinear residual calculation. I do not know if it is PETSc, libmesh or MOOSE that is requesting this second residual calculation.

Impact

Computational efficiency. In the simple physics i happen to be modelling right now, just doing 1 residual calculation would speed up MOOSE by two times!

WilkAndy added a commit to WilkAndy/moose that referenced this issue Jun 28, 2018
I have no idea if this is the best way of addressing this issue, eg, this PR might have lots of side effects!

Fixes idaholab#11760
WilkAndy added a commit to WilkAndy/moose that referenced this issue Jun 28, 2018
I have no idea if this is the best way of addressing this issue, eg, this PR might have lots of side effects!

Fixes idaholab#11760
WilkAndy added a commit to WilkAndy/moose that referenced this issue Jun 28, 2018
I have no idea if this is the best way of addressing this issue, eg, this PR might have lots of side effects!

Fixes idaholab#11760
WilkAndy added a commit to WilkAndy/moose that referenced this issue Jun 28, 2018
I have no idea if this is the best way of addressing this issue, eg, this PR might have lots of side effects!

Fixes idaholab#11760
WilkAndy added a commit to WilkAndy/moose that referenced this issue Jun 28, 2018
I have no idea if this is the best way of addressing this issue, eg, this PR might have lots of side effects!

Fixes idaholab#11760
@permcody permcody added C: Framework T: task An enhancement to the software. P: normal A defect affecting operation with a low possibility of significantly affects. labels Jun 28, 2018
@fdkong
Copy link
Contributor

fdkong commented Jun 28, 2018

OK. The second residual evaluation is added because we are asking PETSc to have a Nonlinear monitor by default. It is not necessary for linear problems. I think the simple solution is to use -snes_monitor_cancel . Then PETSc won't call the residual evaluation again. We may not care about the nonlinear residuals if the problems are linear.

It does not work for you, please kindly let me know.

@permcody
Copy link
Member

Thanks @fdkong for that handy workaround. Is it worth adding an option to MOOSE for truly linear problems? Is there a wider framework change that might benefit people who know they are working with linear problems? I know that libMesh has different system types but you are correct we always assume nonlinear in MOOSE. I'm open to ideas here.

@fdkong
Copy link
Contributor

fdkong commented Jun 28, 2018

solve_type = linear is already a pure linear solver except that we still have some nonlinear monitors. If we cancel out all nonlinear monitors then we end up a pure linear solver which should not have any extra work.

fdkong added a commit to fdkong/moose that referenced this issue Jun 28, 2018
fdkong added a commit to fdkong/moose that referenced this issue Jun 28, 2018
lindsayad pushed a commit to lindsayad/moose that referenced this issue Jun 29, 2018
lindsayad pushed a commit to lindsayad/moose that referenced this issue Jun 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Framework P: normal A defect affecting operation with a low possibility of significantly affects. T: task An enhancement to the software.
Projects
None yet
Development

No branches or pull requests

3 participants