Using FailingProblem from the MooseTestApp in my test app

[mattfalcone1997]

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

I am writing tests for my MOOSE application Hippo. As part of these tests, I am checking that the cut-back works correctly when using fixed-point iteration. To do this, I am trying to use the FailingProblem class from the MooseTestApp, but have been unable to get it to work properly without simply copying the source files. I have tried

1. Adding the MooseTestApp as an application in my MakeFile and calling MooseTestApp::registerAll from my test app, similarly to how Cardinal uses other MOOSE apps.

• FailingProblem is found, but it cannot then find the HeatConduction kernel
• I assume this is because MooseTestApp is not built with the HeatTransfer module, although I am not sure about this.

2. Trying to dynamically load them using

[Problem]
   register_objects_from = 'MooseTestApp'
   library_path = '/path/to/moose/test/lib'
[]

• Using this, the FailingProblem object was not found.

I am wondering if there is something I am missing.

[GiudGiud]

Hello

FailingProblem is a test object. Did you remember to add allow_test_objects = true to the test spec OR to pass --allow-test-objects on the command line?

Trying to dynamically load them using

This should have worked

Adding the MooseTestApp as an application in my MakeFile and calling MooseTestApp::registerAll from my test app, similarly to how Cardinal uses other MOOSE apps.

also should have worked,

assume this is because MooseTestApp is not built with the HeatTransfer module, although I am not sure about this. registering one app does not de-register the others so that should not be the case

[mattfalcone1997]

Okay, I assume I have made some sort of error in the setup. I am following the dynamic approach, and I am reproducing my problem using the thermal hydraulics app to remove the possibility that my MOOSE app is responsible.

I am running this problem:

[Mesh]
    [solid]
        type = GeneratedMeshGenerator
        dim = 3
        nx = 50
    []
[]

[Variables]
    [T]
        family = LAGRANGE
        order = FIRST
        initial_condition = 1
    []
[]


[Kernels]
    [heat-conduction]
        type = HeatConduction
        variable = T
    []
    [heat-conduction-dt]
        type = HeatConductionTimeDerivative
        variable = T
    []
[]

[BCs]
    [fluid_interface]
        type = DirichletBC
        variable = T
        boundary = right
        value = 0
    []
[]

[Materials]
    [thermal-conduction]
        type = HeatConductionMaterial
        thermal_conductivity = 1.0  # W/(m.K)
        specific_heat = 0.05  # J/(kg.K)
    []
    [thermal-density]
        type = GenericConstantMaterial
        prop_names  = 'density'
        prop_values = 20.0  # kg/m3
    []
[]

[Executioner]
    type = Transient
    start_time = 0
    end_time = 0.01
    dt = 0.0003125

    solve_type = 'NEWTON'
    petsc_options = '-snes_ksp_ew'
    petsc_options_iname = '-pc_type -pc_hypre_type'
    petsc_options_value = 'hypre boomeramg'
    nl_abs_tol = 1e-7
    nl_rel_tol = 1e-8
[]

This works fine, but if I add the block

[Problem]
    type=FailingProblem
    register_objects_from = 'MooseTestApp'
    library_path = '/home/mfalcone/SOFTWARE/moose/test/lib'
    object_names = 'FailingProblem'
[]

I get the error:
A 'FailingProblem' is not a registered object.