Antonio

@dschwen @lindsayad This should be ready for review.

> Perhaps add some virtual methods in NonlinearSystemBase and create a NonlinearSystem derived class in the contact module? That'll fix the coverage issue. We'd need to create that contact-specific nonlinear...

Looks great to me, nice cleanup!

> Are there any other ones? Contact should probably be 'contact mechanics'.

That's a bit surprising to me. For both cases (150 and 300), did you configure MOOSE and then compile your application?

You have `std::sqrt`s in your models for AD objects. You could protect against a derivative divide by zero by adding a positive epsilon (see https://github.com/idaholab/moose/blob/ee15815834405de6cc5ccccd988d42a38c0dac6c/modules/contact/src/constraints/ComputeFrictionalForceLMMechanicalContact.C#L223). That might help since it's...

The issue is in the derivative of sqrt(ADReal(0)), which is ~ 1/sqrt(0). It may be that a similar issue is found in other parts of the code, not necessarily yours....

That behavior seems a bit odd to me... @lindsayad

Judging by the back trace it seems the issue is coming from a parsed material: Can you double check your input? Maybe uninitialized values, as Alex pointed out? Or divide...

> I thought for all quantities in the input deck, when we create them in the input deck, the initial value must be provided to complete the definition. I thought...