PerfGraph errors out when used with Reference Residual Problem

[sapitts]

Bug Description

When trying to use the PerfGraphData postprocessor to collect timing/number of calls for residual and jacobian calculations in input files which use ReferenceResidualProblem, the simulations throw an error in the first timestep:

*** ERROR ***
Unknown section_name: FEProblem::computeResidualInternal in PerfGraph::getTime()
If you are attempting to retrieve the root use "Root".

Steps to Reproduce

I've modified an existing regression test for the reference residual problem by adding the PerfGraphData postprocessor for the residual calculation taken from the print_perf_data.i regression test, included in the dropdown below.

Input File to Reproduce the Problem:

[GlobalParams]
  displacements = 'disp_x disp_y disp_z'
[]

[Mesh]
  type = GeneratedMesh
  dim = 3
  nx = 4
  ny = 4
  nz = 4
[]

[Problem]
  type = ReferenceResidualProblem
  solution_variables = 'disp_x disp_y disp_z temp'
  reference_residual_variables = 'saved_x saved_y saved_z saved_t'
[]

[Variables]
  [./disp_x]
    order = FIRST
    family = LAGRANGE
  [../]

  [./disp_y]
    order = FIRST
    family = LAGRANGE
  [../]

  [./disp_z]
    order = FIRST
    family = LAGRANGE
  [../]

  [./temp]
    order = FIRST
    family = LAGRANGE
  [../]
[]

[AuxVariables]
  [./saved_x]
  [../]
  [./saved_y]
  [../]
  [./saved_z]
  [../]
  [./saved_t]
  [../]
[]

[Modules/TensorMechanics/Master]
  [./all]
    volumetric_locking_correction = true
    incremental = true
    save_in = 'saved_x saved_y saved_z'
    eigenstrain_names = thermal_expansion
    strain = FINITE
    decomposition_method = EigenSolution
  [../]
[]

[Kernels]
  [./heat]
    type = HeatConduction
    variable = temp
    save_in = saved_t
  [../]
[]

[Functions]
  [./pull]
    type = PiecewiseLinear
    x = '0 1 2'
    y = '0 1 1'
    scale_factor = 0.1
  [../]
[]

[BCs]
  [./bottom_x]
    type = DirichletBC
    variable = disp_x
    boundary = bottom
    value = 0.0
  [../]

  [./bottom_y]
    type = DirichletBC
    variable = disp_y
    boundary = bottom
    value = 0.0
  [../]

  [./bottom_z]
    type = DirichletBC
    variable = disp_z
    boundary = bottom
    value = 0.0
  [../]

  [./top_x]
    type = DirichletBC
    variable = disp_x
    boundary = top
    value = 0.0
  [../]

  [./top_y]
    type = FunctionDirichletBC
    variable = disp_y
    boundary = top
    function = pull
  [../]

  [./top_z]
    type = DirichletBC
    variable = disp_z
    boundary = top
    value = 0.0
  [../]

  [./bottom_temp]
    type = DirichletBC
    variable = temp
    boundary = bottom
    value = 10.0
  [../]

  [./top_temp]
    type = DirichletBC
    variable = temp
    boundary = top
    value = 20.0
  [../]
[]

[Materials]
  [./elasticity_tensor]
    type = ComputeIsotropicElasticityTensor
    block = 0
    youngs_modulus = 1.0
    poissons_ratio = 0.3
  [../]
  [./stress]
    type = ComputeFiniteStrainElasticStress
    block = 0
  [../]

  [./thermal_expansion]
    type = ComputeThermalExpansionEigenstrain
    block = 0
    eigenstrain_name = thermal_expansion
    temperature = temp
    thermal_expansion_coeff = 1e-5
    stress_free_temperature = 0.0
  [../]

  [./heat1]
    type = HeatConductionMaterial
    block = 0
    specific_heat = 1.0
    thermal_conductivity = 1e-3 #Tuned to give temperature reference resid close to that of solidmech
  [../]

  [./density]
    type = Density
    block = 0
    density = 1.0
  [../]
[]

[Executioner]
  type = Transient
  solve_type = 'PJFNK'

  nl_rel_tol = 1e-10

  l_tol = 1e-3
  l_max_its = 100

  dt = 1.0
  end_time = 2.0
[]

[Postprocessors]
  [./ref_resid_x]
    type = NodalL2Norm
    execute_on = timestep_end
    variable = saved_x
  [../]
  [./ref_resid_y]
    type = NodalL2Norm
    execute_on = timestep_end
    variable = saved_y
  [../]
  [./ref_resid_z]
    type = NodalL2Norm
    execute_on = timestep_end
    variable = saved_z
  [../]
  [./ref_resid_t]
    type = NodalL2Norm
    execute_on = timestep_end
    variable = saved_t
  [../]
  [./nonlinear_its]
    type = NumNonlinearIterations
  []
  [./res_calls]
    type = PerfGraphData
    section_name = "FEProblem::computeResidualInternal"
    data_type = calls
  [../]
  [./elapsed]
    type = PerfGraphData
    section_name = "Root"
    data_type = total
  [../]
[]

[Outputs]
  csv = true
[]

Impact

This error caused a large number of failures in the Bison assessment cases when I tried to add the PerfGraphData pp to all of the assessment cases via an action. We would very much like to use the timing and/or calls of the residual and jacobian computations in our milestone that is due in June if possible.

@permcody and/or @friedmud could I ask you to help me determine if and how we could fix this error please? @bwspenc, @dschwen, @gardnerru, and @tophmatthews this is the regression test I promised in the Bison 1692 merge request

[dschwen]

Well, the section is called ReferenceResidualProblem::computeResidualInternal when you use reference residual problem :-)

[dschwen]

Yeah, PerfGraphInterface prepends moose_object->type() + "::" to the section name. So the "class name" of the current object gets prepended by default. I'm not sure this is ideal. Well, your output action could build the section name as _problem->type() + "::computeResidualInternal" to pass to the postprocessor.

[permcody]

Yeah, PerfGraphInterface prepends moose_object->type() + "::" to the section name. So the "class name" of the current object gets prepended by default. I'm not sure this is ideal.

This was changed intentionally so that Multiapps would print more useful information. Prior to that change you'd get a list of FEProblem::foo type outputs that were all about the same for each Multiapp. You may be right that it's not ideal, but now you have the reasons for that change.

[sapitts]

Super, sounds like it's an easy change for me to make in my action. Is there a way to check within an action to see if ReferenceResidualProblem is or is not present in an input file? We've got a mix of both in the Bison assessment case repository and I'd like to avoid introducing a bazillion parameters in the action if possible Nevermind, I see you gave me the solution already. thanks

I'll make a pull request with a test case with the correction that @dschwen gave for my example test problem as well, just in case anyone else runs into a similar issue as me

[permcody]

The Action BASE CLASS has a _problem pointer on it. The easy thing to do is to dynamically cast that to a specific type and check if it succeeded or not. Note that the pointer will be NULL at the beginning of the simulation and during the build of the mesh so there won't be anything to do but I bet your Action runs at a later time when the problem already exists.

…

On Thu, May 30, 2019 at 4:04 PM Stephanie Pitts ***@***.***> wrote: Super, sounds like it's an easy change for me to make in my action. Is there a way to check within an action to see if ReferenceResidualProblem is or is not present in an input file? We've got a mix of both in the Bison assessment case repository and I'd like to avoid introducing a bazillion parameters in the action if possible I'll make a pull request with a test case with the correction that @dschwen <https://github.com/dschwen> gave for my example test problem as well, just in case anyone else runs into a similar issue as me — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13495?email_source=notifications&email_token=AAXFOIGBYM72T3OGT7TLLSDPYAXOBA5CNFSM4HRH7KTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWTLYQA#issuecomment-497466432>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXFOIGFHTD37B6QGXG2XYTPYAXOBANCNFSM4HRH7KTA> .