Transient analysis appears to fail after solution reaches steady-state

[Alexander Lindsay]

I'm going to ask another question that likely reveals by MOOSE ineptitude...

I was playing around with moose's example 6 which introduces transient analysis. In the un-edited input file, # of steps = 75, and dt = 1. I found that if I make # of steps = 10 and dt = 100, everything works fine and the solution converges. However, if I make # of steps = 20 (dt = 100), the problem diverges around t = 1300s. If I reduce dt to 50, the problem diverges around t = 1100s. If I reduce dt yet again to 25, it diverges around t = 900s. This jives with what I've seen in a very basic application I made: transient analysis seems to fail after the solution reaches an essentially steady-state profile. Can someone explain to me why this happens?

Alex

[Cody Permann]

If you have reached steady-state, your initial residual for each timestep will be very small and the solver may not be able to reach either the next relative tolerance drop or the absolute minimum tolerance which is set _very_ low by default. We can detect this state however. Take a look at the "trans_ss_check" and "ss_check_tol" parameters in the Transient executioner.

Cody

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.
Visit this group at http://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/33373cf5-89ea-4130-9355-42b10a725039%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Derek Gaston]

MOOSE is always trying to "solve" the problem you give it.  If you don't give it anything to do (i.e. you give the exact answer to the current timestep as the initial guess) then it will still TRY to solve... often with negative consequences.  So it's usually a good idea to avoid these kinds of situations.

In this case one option is just to use the steady state finding capabilities in the Transient Executioner.  Set trans_ss_check=true and you can modify the value of ss_check_tol (it defaults to 1e-8).  Both of these are options you set in the Executioner block.

Derek

--

You received this message because you are subscribed to the Google Groups "moose-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

[Alexander Lindsay]

Using the "trans_ss_check" and "ss_check_tol" options work great. Thanks!

[Andrew....@csiro.au]

I will mention this here even though it is probably not relevant to your case.

 

In porous flow (Richards equation) the Jacobian can become difficult to invert when the system is close to steadystate.  Often people use BJACOBI as their preconditioner for the linear solve, because it’s fast most of the time.  Close to steadystate a better choice is pc_type=ASM , sub_pc_type=lu , sub_pc_factor_shift_type=NONZERO .    You can easily detect whether it is the linear or nonlinear (or both, bummer) solves that are failing by using the monitors.

 

a

 

 

Ph: +61 7 3327 4497.  Fax: +61 7 3327 4666
Queensland Centre for Advanced Technologies
PO Box 883, Kenmore, Qld, 4069 
 

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAFfxPjoPWj-zF%3DL416%3D553_8PfBQLg2M7wP%3D61Wxt%3D2-Nq1QZQ%40mail.gmail.com.

[Alexander Lindsay]

Thanks Andrew, I will keep that in mind