PorousFlowSteadyStateDetection

Computes the rate of relative change in a post-processor value over a timestep

Description

PorousFlowSteadyStateDetection computes the relative rate of change, between the current and previous timestep, of a target postprocessor's value normalized by the timestep size. Denoting the current and old values of targetpostprocessor as value/value_old and of dt_postprocessor (the timestep-size postprocessor) as dt/dt_old, the reported value is


abs( (value/dt - value_old/dt_old) / (value_old/dt_old) )

except on the very first (t_step == 0) evaluation, or whenever dt, dt_old, or value_old is 0 (a division guard), where it instead reports the large sentinel 1e30. This quantity trends toward zero as a simulation approaches a steady state, and is typically fed into PorousFlowSteadyStateTerminator to stop a transient once the system has settled.

The sentinel matters for that pairing: PorousFlowSteadyStateTerminator treats a small value as "converged", so a "cannot compute yet" result has to be large rather than 0. Reporting 0 here would make the terminator fire on the very first timestep and hard-stop the run, looking like an instantly-converged steady state. 1e30 reads unambiguously as not steady, and matches the sentinel used for ss_detection_end_time.

Because value_old and dt_old are only meaningful once a postprocessor has been through at least one real timestep transition, feeding this postprocessor a dt_postprocessor whose value is not yet defined at the simulation's initial time (e.g. TimestepSize, whose value before the executioner has set a timestep is 0) reports the sentinel on the first timestep after initialization rather than dividing by zero. The same applies to a cumulative or integral targetpostprocessor, whose value_old is 0 at t0.

Example Input Syntax

[Postprocessors<<<{"href": "../../syntax/Postprocessors/index.html"}>>>]
  [dt_pp]
    type = TimestepSize<<<{"description": "Reports the timestep size", "href": "TimestepSize.html"}>>>
    execute_on<<<{"description": "The list of flag(s) indicating when this object should be executed. For a description of each flag, see https://mooseframework.inl.gov/source/interfaces/SetupInterface.html."}>>> = 'initial timestep_end'
  []
  [target]
    type = FunctionValuePostprocessor<<<{"description": "Computes the value of a supplied function at a single point (scalable)", "href": "FunctionValuePostprocessor.html"}>>>
    function<<<{"description": "The function which supplies the postprocessor value."}>>> = target_fn
    execute_on<<<{"description": "The list of flag(s) indicating when this object should be executed. For a description of each flag, see https://mooseframework.inl.gov/source/interfaces/SetupInterface.html."}>>> = 'initial timestep_end'
  []
  [computed]
    type = PorousFlowSteadyStateDetection<<<{"description": "Computes the rate of relative change in a post-processor value over a timestep", "href": "PorousFlowSteadyStateDetection.html"}>>>
    targetpostprocessor<<<{"description": "The name of the targetpostprocessor"}>>> = target
    dt_postprocessor<<<{"description": "The name of the timestep-size postprocessor"}>>> = dt_pp
  []
  [exact]
    type = FunctionValuePostprocessor<<<{"description": "Computes the value of a supplied function at a single point (scalable)", "href": "FunctionValuePostprocessor.html"}>>>
    function<<<{"description": "The function which supplies the postprocessor value."}>>> = exact_fn
  []
  [residual]
    type = ParsedPostprocessor<<<{"description": "Computes a parsed expression with post-processors", "href": "ParsedPostprocessor.html"}>>>
    pp_names<<<{"description": "Post-processors arguments"}>>> = 'computed exact'
    expression<<<{"description": "function expression"}>>> = 'abs(computed - exact)'
  []
[]

Input Parameters

dt_postprocessorThe name of the timestep-size postprocessor
C++ Type:PostprocessorName
Unit:(no unit assumed)
Controllable:No
Description:The name of the timestep-size postprocessor
targetpostprocessorThe name of the targetpostprocessor
C++ Type:PostprocessorName
Unit:(no unit assumed)
Controllable:No
Description:The name of the targetpostprocessor

Required Parameters

allow_duplicate_execution_on_initialFalseIn the case where this UserObject is depended upon by an initial condition, allow it to be executed twice during the initial setup (once before the IC and again after mesh adaptivity (if applicable).
Default:False
C++ Type:bool
Controllable:No
Description:In the case where this UserObject is depended upon by an initial condition, allow it to be executed twice during the initial setup (once before the IC and again after mesh adaptivity (if applicable).
execute_onTIMESTEP_ENDThe list of flag(s) indicating when this object should be executed. For a description of each flag, see https://mooseframework.inl.gov/source/interfaces/SetupInterface.html.
Default:TIMESTEP_END
C++ Type:ExecFlagEnum
Options:XFEM_MARK, NONE, INITIAL, LINEAR, LINEAR_CONVERGENCE, NONLINEAR, NONLINEAR_CONVERGENCE, POSTCHECK, TIMESTEP_END, TIMESTEP_BEGIN, MULTIAPP_FIXED_POINT_END, MULTIAPP_FIXED_POINT_BEGIN, MULTIAPP_FIXED_POINT_CONVERGENCE, MULTISYSTEM_FIXED_POINT_ITERATION_END, FINAL, CUSTOM, TRANSFER
Controllable:No
Description:The list of flag(s) indicating when this object should be executed. For a description of each flag, see https://mooseframework.inl.gov/source/interfaces/SetupInterface.html.
execution_order_group0Execution order groups are executed in increasing order (e.g., the lowest number is executed first). Note that negative group numbers may be used to execute groups before the default (0) group. Please refer to the user object documentation for ordering of user object execution within a group.
Default:0
C++ Type:int
Controllable:No
Description:Execution order groups are executed in increasing order (e.g., the lowest number is executed first). Note that negative group numbers may be used to execute groups before the default (0) group. Please refer to the user object documentation for ordering of user object execution within a group.
force_postauxFalseForces the UserObject to be executed in POSTAUX
Default:False
C++ Type:bool
Controllable:No
Description:Forces the UserObject to be executed in POSTAUX
force_preauxFalseForces the UserObject to be executed in PREAUX
Default:False
C++ Type:bool
Controllable:No
Description:Forces the UserObject to be executed in PREAUX
force_preicFalseForces the UserObject to be executed in PREIC during initial setup
Default:False
C++ Type:bool
Controllable:No
Description:Forces the UserObject to be executed in PREIC during initial setup

Execution Scheduling Parameters

control_tagsAdds user-defined labels for accessing object parameters via control logic.
C++ Type:std::vector<std::string>
Controllable:No
Description:Adds user-defined labels for accessing object parameters via control logic.
enableTrueSet the enabled status of the MooseObject.
Default:True
C++ Type:bool
Controllable:Yes
Description:Set the enabled status of the MooseObject.
outputsVector of output names where you would like to restrict the output of variables(s) associated with this object
C++ Type:std::vector<OutputName>
Controllable:No
Description:Vector of output names where you would like to restrict the output of variables(s) associated with this object
use_displaced_meshFalseWhether or not this object should use the displaced mesh for computation. Note that in the case this is true but no displacements are provided in the Mesh block the undisplaced mesh will still be used.
Default:False
C++ Type:bool
Controllable:No
Description:Whether or not this object should use the displaced mesh for computation. Note that in the case this is true but no displacements are provided in the Mesh block the undisplaced mesh will still be used.

Advanced Parameters

prop_getter_suffixAn optional suffix parameter that can be appended to any attempt to retrieve/get material properties. The suffix will be prepended with a '_' character.
C++ Type:MaterialPropertyName
Unit:(no unit assumed)
Controllable:No
Description:An optional suffix parameter that can be appended to any attempt to retrieve/get material properties. The suffix will be prepended with a '_' character.
use_interpolated_stateFalseFor the old and older state use projected material properties interpolated at the quadrature points. To set up projection use the ProjectedStatefulMaterialStorageAction.
Default:False
C++ Type:bool
Controllable:No
Description:For the old and older state use projected material properties interpolated at the quadrature points. To set up projection use the ProjectedStatefulMaterialStorageAction.

Material Property Retrieval Parameters

Input Files

(test/tests/postprocessors/porous_flow_steady_state_detection/pair.i)
(test/tests/postprocessors/porous_flow_steady_state_detection/inp.i)

(test/tests/postprocessors/porous_flow_steady_state_detection/inp.i)

# Analytic verification of PorousFlowSteadyStateDetection.
#
# PorousFlowSteadyStateDetection::getValue() returns the sentinel 1e30 at t_step == 0, or whenever
# dt, dt_old, or value_old is 0 (division guard), and otherwise
#   abs( (value/dt - value_old/dt_old) / (value_old/dt_old) )
# where value/value_old and dt/dt_old are the current/old values of the target and dt
# postprocessors.
#
# Drive with dt_postprocessor = TimestepSize and targetpostprocessor(t) = 5 + t, so that
# value_old is always 1 less than value. TimestepSize's value at the initial time (before the
# Transient executioner has set a timestep size) is 0, so the "old" dt recorded for the first
# timestep (t_step=1) is 0 -- this exercises the division guard directly, rather than stepping
# around it with a constant dt postprocessor.
#
#   t_step=0 (t=0): the guard applies (not evaluated into the CSV, since this postprocessor's own
#                   execute_on is the default, timestep_end only)
#   t_step=1 (t=1): dt_old=0, so the division guard reports the 1e30 sentinel
#   t_step=k (t=k), k=2..6: dt=dt_old=1 (cancels), value=5+k, value_old=5+(k-1)=4+k
#                   change = (value-value_old)/value_old = 1/(4+k)
#
# so exact(t) = 1e30 for t=1, and 1/(4+t) for t = 2..6 (recalling dt=1 so t and t_step coincide
# numerically). The sentinel must be large, not 0: see pair.i, which pins down why.

[Mesh/mesh]
  type = GeneratedMeshGenerator
  dim = 1
[]

[Problem]
  kernel_coverage_check = false
  solve = false
[]

[Functions]
  [target_fn]
    type = ParsedFunction
    expression = '5 + t'
  []
  [exact_fn]
    type = ParsedFunction
    expression = 'if(t <= 1, 1e30, 1/(4 + t))'
  []
[]

[Postprocessors]
  [dt_pp]
    type = TimestepSize
    execute_on = 'initial timestep_end'
  []
  [target]
    type = FunctionValuePostprocessor
    function = target_fn
    execute_on = 'initial timestep_end'
  []
  [computed]
    type = PorousFlowSteadyStateDetection
    targetpostprocessor = target
    dt_postprocessor = dt_pp
  []
  [exact]
    type = FunctionValuePostprocessor
    function = exact_fn
  []
  [residual]
    type = ParsedPostprocessor
    pp_names = 'computed exact'
    expression = 'abs(computed - exact)'
  []
[]

[Executioner]
  type = Transient
  dt = 1
  num_steps = 6
[]

[Outputs]
  csv = true
[]

(test/tests/postprocessors/porous_flow_steady_state_detection/pair.i)

# Regression test for PorousFlowSteadyStateDetection wired to PorousFlowSteadyStateTerminator --
# the pairing both doc pages recommend, and which no single input exercised before.
#
# PorousFlowSteadyStateDetection cannot compute a relative rate of change on the first timestep
# (TimestepSize's "old" value is 0 there), nor whenever the target's old value is 0 (the normal
# state of a cumulative or integral quantity at t0). For those cases it reports a large sentinel,
# 1e30.
#
# It must NOT report 0. The terminator below treats a SMALL value as converged, so with its default
# ss_relative_error = 1e-2 and ss_detection_start_time = 0, a 0 would satisfy
#   value <= ss_relative_error && t > ss_detection_start_time
# on the very first step, and the Terminator UserObject would hard-stop the run one step in --
# reporting an instantly-converged steady state. Both parameters are deliberately left at their
# defaults here, because it is the defaults that make that the observable failure.
#
# The target is deliberately far from steady: target(t) = 5 + t gives a relative rate of change of
# 1/(4 + t), which is still 0.1 at the last step -- an order of magnitude above ss_relative_error.
# The terminator must therefore never fire and the run must reach all 6 steps.
#
# If the sentinel ever regresses to 0, the Terminator fires at t = 1, the CSV is truncated, and
# CSVDiff's row-count check turns that into a failure.

[Mesh/mesh]
  type = GeneratedMeshGenerator
  dim = 1
[]

[Problem]
  kernel_coverage_check = false
  solve = false
[]

[Functions]
  [target_fn]
    type = ParsedFunction
    expression = '5 + t'
  []
[]

[Postprocessors]
  [dt_pp]
    type = TimestepSize
    execute_on = 'initial timestep_end'
  []
  [cur_time]
    type = TimePostprocessor
  []
  [target]
    type = FunctionValuePostprocessor
    function = target_fn
    execute_on = 'initial timestep_end'
  []
  [ss_detect]
    type = PorousFlowSteadyStateDetection
    targetpostprocessor = target
    dt_postprocessor = dt_pp
  []
  [ss_term]
    type = PorousFlowSteadyStateTerminator
    targetpostprocessor = ss_detect
    timepostprocessor = cur_time
    # ss_relative_error, ss_detection_start_time and ss_detection_end_time all left at defaults.
  []
[]

[UserObjects]
  [terminate_on_steady_state]
    type = Terminator
    expression = 'ss_term > 0.5'
    message = 'PorousFlowSteadyStateTerminator reported steady state'
  []
[]

[Executioner]
  type = Transient
  dt = 1
  num_steps = 6
[]

[Outputs]
  csv = true
[]