pp for fixed point convergence

[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 have a multi-app system set up like this

[MultiApps]
  [fracture]
    type = TransientMultiApp
    input_files = 'fracture.i'
    cli_args = 'l=${l}'
    execute_on = 'TIMESTEP_END'
  []
[]

[Transfers]
  [send_psie_active]
    type = MultiAppGeneralFieldShapeEvaluationTransfer
    to_multi_app = fracture
    source_variable = psie_active
    variable = psie_active
  []
  [send_psii_active]
    type = MultiAppGeneralFieldShapeEvaluationTransfer
    to_multi_app = fracture
    source_variable = psii_active
    variable = psii_active
  []
  [get_d]
    type = MultiAppGeneralFieldShapeEvaluationTransfer
    from_multi_app = fracture
    source_variable = d
    variable = d
  []
[]

(phase-field stuff)

I am trying to set the convergence for my picard iterations to be
||d^k-d^(k-1)|| < TOL
Where k is the current picard iteration So, the L2 norm of the difference between the value before and after the subapp solves is my tolerance criterion.

For the life of me I cannot get this to work.
I have tried two ways, the first way just using AuxVariables and the NodalL2Norm post processor. The second is with a custom post-processor.

For the first method I set up 3 AuxVariables I will call d d_old and d_diff.
d is the value being passed back from the subapp, d_old is the value copied at MULTIAPP_FIXED_POINT_BEGIN and d_diff is the difference between the two.
I then feed d_diff into the NodalL2Norm post process, which I then call in the custom_pp argument in the executioner block.
However, in this case, the post-processor always returns a zero value.

The second way I feed a custom post processor, with this body,

InputParameters
SolutionChangeNorm::validParams()
{
  InputParameters params = ElementIntegralPostprocessor::validParams();
  params.addClassDescription(
      "This class computes the solution change (L2) norm of selected variables.");
  params.addRequiredCoupledVar("variable",
                               "The names of the variables that this object operates on");
  return params;
}

SolutionChangeNorm::SolutionChangeNorm(const InputParameters & parameters)
  : ElementIntegralPostprocessor(parameters),
    _us(coupledValues("variable")),
    _us_old(coupledValuesOld("variable"))
{
}

Real
SolutionChangeNorm::getValue() const
{
  return std::sqrt(ElementIntegralPostprocessor::getValue());
}

Real
SolutionChangeNorm::computeQpIntegral()
{
  Real value = 0;
  for (unsigned int i = 0; i < _us.size(); i++)
    value += MathUtils::pow((*_us[i])[_qp] - (*_us_old[i])[_qp], 2);
  return value;
}

into the custom_pp argument.

However, in this case, I see the following output (where the post processor is delta_d,

where the pp residual is zero, but in the output step, it shows that the post-processor did have a value (3.599e-2).

I'd appreciate any help in fixing either of these methods if possible.
(or if there is already functionality for this in MOOSE that I am unaware of)

Also, a smaller question. How does the relaxation factor work? Is there a way to specify which variable I want it applied to? Or does it just apply to any variable coming from the multi-app?

[GiudGiud]

Hello

where the pp residual is zero, but in the output step, it shows that the post-processor did have a value (3.599e-2).

When is delta_d executed?
And when is the CSV output ? (execute_on) flags?

Also, a smaller question. How does the relaxation factor work? Is there a way to specify which variable I want it applied to? Or does it just apply to any variable coming from the multi-app?

Yes it is applied to the transformed_variables. Which can only be main app parent variables at this time ( there's a PR for auxvariables)

[GiudGiud]

[DBG] Computing elemental user objects on MULTIAPP_FIXED_POINT_END
[DBG] Ordering of User Objects on block 19
[DBG] Executing SolutionChangeNorm on MULTIAPP_FIXED_POINT_END

how about executing those on timestep_end instead?

[TheGreatCid]

For debugging I had it outputting on fixed point begin, fixed point end, and timestep end

[TheGreatCid]

The issue is that the variable being changed is the variable being solved for in the subapp. It is one value before the solve, and then another value after. I want to use the difference in that value for the convergence criterion.

[GiudGiud]

I only see fixed point end in the log.

The issue is that the variable being changed is the variable being solved for in the subapp. It is one value before the solve, and then another value after. I want to use the difference in that value for the convergence criterion.

and you are transferring before and after and then taking the difference?
Using problem/verbose_multiapps = true you can see if that actually works. You need the transfers to occur in a specific order.
I would do this using two variables, one for "before the multiapp runs" and one for "app the multiapp runs" rather using the old / current coupleable apis

[TheGreatCid]

Got it thanks! I'll investigate