Help picking out preconditioners

[TheGreatCid]

Check these boxes if you have followed the posting rules.

• Q&A General is the most appropriate section for my question
• I have consulted the posting Guidelines on the Discussions front page
• I have searched the Discussions forum and my question has not been asked before
• I have searched the MOOSE website and the documentation does not answer my question
• I have formatted my post following the posting guidelines (screenshots as a last resort, triple back quotes around pasted text)

Question

Hi all,

I am looking for some insight into the best preconditioners to use for a large 3D problem.
I am performing a monolithic solve between displacements and temperature. I am using an Implicit Euler time integrator, with all the HHT alpha parameters provided to the relevant inertial Kernels/AuxKernels.

Here are the specifics for each model:
Solid Mechanics

• Inertial Kernels
• Dynamic Stress Divergence Kernels
• J2 Plasticity
• Finite Strain
• Hyperelasticity

Temperature

• Conduction Kernel
• Time Derivative Kernel
• Source Kernel

The mechanical and temperature solves are coupled through the J2 plasticity solve. Plastic work generates heat while the temperature degrades the yield surface. Steep temperature and plastic strain gradients form over the course of the simulation.

I am looking for advice on speeding up the calculation (if possible) and improving overall performance (fewer NL its, less ping-ponging, etc.). At a certain point in the simulation, the NL It's will ping-pong, requiring a very small timestep to avoid this behavior. I use a Newton NL solver.

By default, I use boomeramg for everything, with the following values,

petsc_options_iname = '-pc_type -pc_hypre_type -ksp_gmres_restart -pc_hypre_boomeramg_strong_threshold -pc_hypre_boomeramg_interp_type -pc_hypre_boomeramg_coarsen_type -pc_hypre_boomeramg_agg_nl -pc_hypre_boomeramg_agg_num_paths -pc_hypre_boomeramg_truncfactor'
petsc_options_value = 'hypre boomeramg 301 0.25 ext+i PMIS 4 2 0.4'

Which tends to work. This performs many linear iterations very quickly. However, I am suspicious that lumping the displacements and the Temp together might be causing issues, as the temperature typically has the outlier residual at the end of a timestep.

I have been trying to implement Schur splitting and run difference PCs on the Temperature variable, but I have found this to be pretty slow. Also, I have been playing a guessing game about what would be best for the Temp variable...

I am curious if anything immediately stands out to anyone who is more experienced in fine-tuning PCs.

[GiudGiud]

Hello

I use a Newton NL solver.

Is the Jacobian fully implemented? What do you get from the finite difference based testing you can find here (-snes test jacobian)
https://mooseframework.inl.gov/moose/application_usage/failed_solves.html

as the temperature typically has the outlier residual at the end of a timestep.

are you using scaling factors? The equations for conservation of energy and mechanics don't have the same magnitude of coefficients

[TheGreatCid]

It is a strong coupling. Plastic work generates, and heat and high temperatures cause softening of the J2 yield surface.
A big point I failed to mention earlier is that the temperature used in the J2 yield surface is lagged. So I use the old temperature for the plasticity update. In theory, that should alleviate the ping-ponging NL its. Of course, that is not what I observe.
Would you anticipate that the locally coupled update would perform better than a lagged method?

I haven't had too much issue with a 2.5D simulation using Hex8 elements. I'm having some trouble with a full 3D simulation using TET10s.

[hugary1995]

Algorithmically the locally coupled update shouldn't give you better stability compared to a lagged temperature. I am running out of ideas for potential causes of the convergence issue. Right now I am entirely guessing:

• try HEX8 instead of TET10 for your 3D problem
• see if temperature field or plastic strain has local oscillations when you run into convergence issues. That may hint at a potentially too big of a time step, and a locally coupled update would help significantly.

[TheGreatCid]

Got it. The pingponging is fixed by lowering the timestep, however, it tends to be prohibitively small.

There are some pretty steep temperature gradients in this problem, and points where T_n and T_{n+1} do differ significantly. The lagged solver is most likely causing some issues during those steps with a large delta_T. The fact that I am using a lagged solver slipped my mind until this discussion ha. I'll go ahead and try out the coupled local update. Thanks for the advice!

[GiudGiud]

The pingponging is fixed by lowering the timestep,

NL pingponging?
Because lagging the temperature field causes your time integration scheme to become partially explicit, which could cause stability issues and time-step iteration pingponging.

[TheGreatCid]

Yes, lowering the timestep stops the NL pingponging.
Hm, that's a good point. More reason to try out the non-lagged version.