Make "Scale BC Dofs: true" option with scaling computed on the fly default for LCM?

[ikalash]

This is a follow on issue to sandialabs/Albany#307 . Now that "Scale BC Dofs: true" is working correctly and I have added a version of it that computes / adapts the scaling on the fly, should we make this option default for LCM? One thing to consider is this sort of change may require rebaselining a lot of the tests that use exodiff (e.g., if the gold file has a residual field, which will change with the scaling).

[lxmota]

Yes, let's make this the default.

[ikalash]

Ok. Let me see what happens first if I make it the default, namely how many tests will need to be rebaselined. I'll post the results here.

[ikalash]

I started working on this. When I force the LCM problems to use 'Scale BC Dofs: true' with the automatically-generated scaling, I am getting the following test failures:

Small tests:

       2 - DomainTear2D_BaseProblem (Failed)
          3 - DomainTear2D_CopyRemesh (Failed)
         23 - Dynamics (Failed)
         57 - MechWithHydrogenFastPath_channel_diffusion (Failed)
         60 - Mechanics2D_J2 (Failed)
         63 - MechanicsPorePressureSimple_Serial (Failed)
         67 - MechanicsTensileCT (Failed)
         68 - MechanicsWithHelium_JustMechanics (Failed)
         91 - SurfaceElementOrtiz (Failed)

Large tests:

     The following tests FAILED:
          1 - CrystalPlasticity_SingleElement2d_ElasticShear2d (Failed)
          2 - CrystalPlasticity_SingleElement3d_ElasticShear3d (Failed)
          3 - CrystalPlasticity_SingleElement3d_ElasticShearRotated3d (Failed)
         13 - CrystalPlasticity_MultiSlipHard_Implicit_Active_Sets (Failed)
         15 - CrystalPlasticity_MinisolverStep_Newton (Failed)
         16 - CrystalPlasticity_MinisolverStep_NewtonLineSearch (Failed)
         17 - CrystalPlasticity_MinisolverStep_TrustRegion (Failed)
         21 - CrystalPlasticity_ThermallyActivatedSlip (Failed)
         27 - MechanicsWithHydrogenBar_no_stabilization (Failed)
         28 - MechanicsWithHydrogenBar_requires_stabilization (Failed)

Some of these seem to "fail" trivially (there are minor differences found by exodiff), but some give very different results. Specifically, it seems most (all?) of the tests that fail non-trivially give a fundamentally different continuation history, e.g., for the MechanicsWithHelium problem:

1: Maximum Number of Continuation Steps = 100
1: Start of Continuation Step 0 : Attempting to converge initial guess at initial parameter values.
1: End of Continuation Step 0 : Parameter: Time = 0.000e+00
1: Start of Continuation Step 1 : Parameter: Time = 5.000e-01 from 0.000e+00
1: End of Continuation Step 1 : Parameter: Time = 3.344e-01 from 0.000e+00
1: Start of Continuation Step 2 : Parameter: Time = 4.452e-01 from 3.344e-01
1: End of Continuation Step 2 : Parameter: Time = 4.382e-01 from 3.344e-01
1: Start of Continuation Step 3 : Parameter: Time = 5.373e-01 from 4.382e-01
1: End of Continuation Step 3 : Parameter: Time = 5.373e-01 from 4.382e-01

Does anyone have any insight into why that would be the case with the scaling? The nonlinear solves converge just fine with the scaling, so it is not like they are failing, leading to the strange behavior.

The way I am doing this, one can always over-write the default turning on of the scaling from parameter list to run w/o scaling; but I would like to understand why this behavior happens for some of the tests with the scaling. @jwfoulk , @lxmota : any thoughts?

[lxmota]

This doesn't surprise me. It may be that the solutions are still correct. These problems are very sensitive to anything you change. We need to verify manually if they are correct and re-bless then. Not ideal, but they are too sensitive.