Damper that bounds the values of a variable during solution

[bwspenc]

Description of the enhancement or error report

Create a Damper that limits the value of a variable to be within user-prescribed minimum or maximum values.

Rationale for the enhancement or information for reproducing the error

We commonly use the MaxIncrement Damper to prevent the temperature from going negative during solutions of the heat equation. This usually works, but picking a permissible temperature increment that prevents this issue but doesn't unduly interfere with the solution of the problem is an art. It would be better to simply specify the permissible minimum value of the temperature. Also, the MaxIncrement Damper is applied at quadrature points. It would be better to do this check at nodes.

Identified impact

Because we would like to apply this to nodes rather than quadrature points, we would need to create a new NodalDamper base class, as well as a class for this specific damper.

[permcody]

@fdkong, @friedmud, @andrsd - before we start down this path. I just want to make sure Ben's assessment is reasonable and that this is the right course of action. Any comments?

[bwspenc]

I actually kinda started down this path already. I have a PR that I'll submit in a bit that I'd like your comments on.

[fdkong]

Is it possible to form the problem as a constrained problem? And then reform the constrained problem as a nonlinear problem. Solve it using Newton. Now, look likes you are manually changing the solution to what you want.

[andrsd]

@bwspenc If you are solving for temperature, go look at test/tests/auxkernels/bounds/bounds_test.i to see how you can bound its values. May be this will work for you rather then doing a nodal damper... (unless you already tried it...)

[bwspenc]

@andrsd I wasn't aware of the Bounds stuff. I looked at the test and the code, but it's not totally obvious what it's doing. It looks like it's filling in a couple of vectors with the upper and lower bounds and passing them to the solver to constrain it. I take it that PETSc has some sort of built-in support for bounds on the solution. Is that the case? If so, that may be exactly what I was after here.

A variable has to be passed in to the BoundsAux object because it's implemented as an AuxKernel, but it doesn't seem like that's used for anything. Is that right? That seems a little weird -- like an AuxKernel maybe isn't really the right thing to use for that.

[fdkong]

@bwspenc, the reason I am asking you questions before is that there is an existing nonlinear solver in PETSc which allows you specify solution like, xl <= x <= xu. xl is lower bound and xu is upper bound.

[bwspenc]

Yeah, @fdkong I see that, and it looks like the existing Bounds capability uses that. Does anyone know if the Bounds stuff widely used? Is there much extra overhead associated with using the solver with bounds in PETSc?

This seems like something we would use a lot, but the user interface for it is really counter-intuitive. AuxKernels usually set the values of AuxVariables, but these set the values of vectors that are hidden to the user. Why not have the user create AuxVariables for the upper and lower bounds, use AuxKernels to populate those variables, and then have some mechanism to tell the the solver to use those for the bounds? Or maybe we can just hide some of the weirdness from the user in the Action that is already used for this.

[friedmud]

@fdkong @andrsd this isn't a case of a "constrained" problem. The real solution lies between the admissible values. The issue is that the Newton solver can travel outside that range during the nonlinear solve (by accident).

@bwspenc : I think a new Damper is the right idea here. That Damper really should have always existed...

One more note to @fdkong : If a "constraint" were needed here then the Damper would actually keep the nonlinear solve from ever converging. It wouldn't allow the solution to go to the minimum the Newton solver wants to find. A real constraint would fix that by shifting the minimum due to the constraint.

If he can use this Damper... and the Newton solver is able to get to a true minimum then all that was needed was some "guidance" and not a true constraint.

[bwspenc]

@friedmud Does the bounds stuff in PETSc do essentially the same thing that the Damper would do? Is it better to let PETSc do that internally or for us to do it using a Damper?

[fdkong]

@fdkong @andrsd this isn't a case of a "constrained" problem. The real solution lies between the admissible values. The issue is that the Newton solver can travel outside that range during the nonlinear solve (by accident).

Do you mean that the true solution actually is the minimum point without any constraints (admissible area is open)? The Newton somehow is not good enough and gives you a perturbed solution which is not the minimum point. The perturbed solution does not make sense physically, for example, negative temperature. You therefore use a damper to force the Newton converge to a physics solution you want.

The nonlinear solver PETSc, SNESVI, is developed for variational inequality problems and allows users specify the bounds of the solution.

@bwspenc : I think a new Damper is the right idea here. That Damper really should have always existed...

One more note to @fdkong : If a "constraint" were needed here then the Damper would actually keep the nonlinear solve from ever converging. It wouldn't allow the solution to go to the minimum the Newton solver wants to find. A real constraint would fix that by shifting the minimum due to the constraint.

If he can use this Damper... and the Newton solver is able to get to a true minimum then all that was needed was some "guidance" and not a true constraint.

[andrsd]

I looked at the test and the code, but it's not totally obvious what it's doing

I recall that the test was kind of weird when I looked at it, because of the limits it was trying to enforce, but it is still a good starting point. If you follow the pattern, you can get what you need.

A variable has to be passed in to the BoundsAux object because it's implemented as an AuxKernel, but it doesn't seem like that's used for anything. Is that right?

Yes, there is a dummy auxvar that is not used and there are 2 vectors to specify upper and lower limit. These are set by the aux kernel.

I take it that PETSc has some sort of built-in support for bounds on the solution. Is that the case? If so, that may be exactly what I was after here.

Yes, that's what @fdkong was talking about...

Does anyone know if the Bounds stuff widely used?

I do not know if widely, but I used it in RELAP to constrain volume fraction between (0..1), and other variables to stay positive (like densities and total energies). The mechanism did not work 100% of the time (meaning it failed for some other problems), but it definitely was doing something right that allowed us to solve some problems... Note that you have to use the right -snes_type (AFAIK) based on the the solve_type. For NEWTON it is vinewtonssls, and for PJFNK it is vinewtonrsls. And think the test is not doing this...

Why not have the user create AuxVariables for the upper and lower bounds, use AuxKernels to populate those variables

I am assuming that PETSc needs 2 full vectors (one for upper and one for lower bound), so creating an aux would give you just part of the full vector. I think that the aux kernels are setting these subparts.

[bwspenc]

If you have to use certain solve types in PETSc for this to work, that's an argument for doing it using a Damper in MOOSE because the Damper would work regardless of the solve type.

[fdkong]

If you have to use certain solve types in PETSc for this to work, that's an argument for doing it using a Damper in MOOSE because the Damper would work regardless of the solve type.

Users still has the same interfaces, and do not need to do any extra stuffs. Of course, you need to pass bounds to PETSc. @bwspenc

[andrsd]

If you have to use certain solve types in PETSc for this to work, that's an argument for doing it using a Damper

That's just a gap in the code - we could probably set the right snes type based on solve_type.

Another part of this problem of not hitting values outside some bounds is that we cannot control it during the linear solve (and that's our current problem in RELAP). This mechanism is only active (AFAIK) when we do the NL step. Not sure if I am describing it properly, but that's how I understood it when Dmitry explained to me.

And I do see how damper would prevent these negative values either, because we compute dampers during the NL step only. They are not evaluated during the linear iterations, right?

[dschwen]

@fdkong we have cases like this in Phase Field and Marmot where the solution is within a certain interval, but residual evaluations can occur during the solve that sample regions outside the interval (where things like the log of a negative number may occur). This makes the solve very fickle because it will fail with nan (even though this is completely avoidable by means of a Damper for example).

[bwspenc]

@andrsd Yes, the dampers only get applied on the NL steps, so you could go outside the bounds on a linear step.

[friedmud]

The capabilities are not mutually exclusive. Both constrained minimization and damped Newton have their place.

In my mind you need to solve a problem that includes the constraints in the case where the true solution (the solution Newton would find without constraints) lies in an inadmissible area. The constraints modify your problem so that you are no longer just trying to minimize the nonlinear residual... you're trying to minimize that and satisfy constraints. The minimum of the augmented problem will then lie within the bounds you set.

Damped Newton serves a similar purpose to Line Search. The true minimum (that Newton would find if it could) lies in a physically valid region... but the solver tries to go outside of that during the nonlinear iterations. That can happen for any number of reasons (initial guess is poor, poor linear solve giving a poor descent direction, etc.). Damping simply keeps the nonlinear updates from "accidentally" venturing into non-physical regions during the nonlinear steps.

Basic difference: Damped Newton does not change the problem you are solving. The minimum it finds (if it does find one) is the same as it would find if it could get there without the damping... whereas... solving a constrained problem changes the problem. The minimum you find is actually different from the one you would find if Newton were to have its way (of course, that depends on applying it to a problem where the true minimum lies outside the bounds).

Both are valid approaches... but for solving different kinds of issues.

Derek

On Wed, Oct 12, 2016 at 1:33 PM Ben Spencer notifications@github.com wrote:

@andrsd https://github.com/andrsd Yes, the dampers only get applied on the NL steps, so you could go outside the bounds on a linear step.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/idaholab/moose/issues/7856#issuecomment-253282403, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1JMS_UHD-ccM19XF0zsfIrhiQNN-aIks5qzRn6gaJpZM4KUuO_ .

[bwspenc]

Makes sense. I'll go ahead and submit my PR that implements this as a Damper.