What may a "Parameter _fe_problem_base is NULL" means?

[WayneX-Wong]

Hi all,

I'm trying to modify a MOOSE-based app to have my custom ability. The compilation process went smoothly, while when I run, an error raised "Parameter _fe_problem_base is NULL". What could be the reason for this error?

I inherit my custom UserObject from TransientInterface to use _t to get current time, where I speculate that the problem may be. My custom UserObject indeed inherited from FEProblemBase, so I don't know exactly what the problem is.

Please let me know if more information about my modification needed. And any suggestions will be appreciated!

[GiudGiud]

Hello

It s very odd that your user object inherits from FEProblemBase and user objects.
So that might be challenging.
What are you trying to do?

The parameter error is not hard to fix I think. You need to find where it's retrieving the _fe_problem_base pointer parameter, and either change that code OR set the parameter like this:

params.set<FEProblemBase *>("_fe_problem_base") = &_fe_problem;

before retrieving it

Guillaume

[aprilnovak]

Ah, sorry for not catching that. I think you need to have OpenMCCellAverageProblem inherit from FunctionInterface. I think you should be able to follow the pattern for how OpenMCProblemBase derives from PostprocessorInterface.

[WayneX-Wong]

Sorry for the late reply. I still have above doubts. I inherited OpenMCProblemBase from FunctionInterface and TransientInterface, completely following the way of inheriting PostprocessorInterface. There are no issues with the compilation process, but the compiled Cardinal-opt still raises an error of

'Parameter _fe_problem_base is NULL'

during runtime. I found the error raised at line24 of FunctionInterface.C. Compared to PostprocessorInterface, FunctionInterface and TransientInterface have different ways of constructors definitions. I think the problem may lie here, but I cannot clearly tell.

Here are my specific modifications:

1. In OpenMCProblemBase. h, include "FunctionInterface. h" and "TransientInterface. h"

2. Initialize FunctionInterface(this) and TransientInterface(this) in the constructor of the OpenMCProblemBase in OpenMCProblemBase. C

3. Forward declare the class Function in OpenMCCellAverageProblem. h and declare a Function object member _function in OpenMCCellAverageProblem to receive functions from the input deck.

4. In OpenMCCellAverageProblem. C, include "openmc/surface. h" and "Function. h", add params. addRequiredParam<FunctionName> in validParams() to receive the function name from the input deck, and initialize in the OpenMCCellAverageProblem constructor _ function (getFunctionByName()), finally used in setupProblem using _ function ->value() to modify geometry.

I've tried this also

params.set<FEProblemBase *>("_fe_problem_base") = &_fe_problem;

But it gives a "_fe_problem was not declared in this scope" during compilation.

[GiudGiud]

so in the transient interface you have

TransientInterface::TransientInterface(const MooseObject * moose_object)
  : _ti_params(moose_object->parameters()),
    _ti_feproblem(*_ti_params.getCheckedPointerParam<FEProblemBase *>("_fe_problem_base")),

this is likely how it s failing.
Whatever mooseobject you are using to build the transient interface (in your constructor: you must have TransientInterface(SOMETHING) somewhere already) needs to have the fe_problem_base parameter already set.
This is usually done by the Action constructing the object. This is an intermediate layer between the input file and the creation of objects.

Maybe this is not the way though. Like we need to re-consider the design
TransientInterface is meant for objects, not for problems.
And having a user object be a Problem is odd as well.

[aprilnovak]

Hi @WayneX-Wong the actual issue is that the Problem classes in MOOSE are constructed before pretty much any other objects (except the [Mesh]). So within the constructor for OpenMCCellAverageProblem, functions, postprocessors, and user objects don't exist yet. So you need to fetch the function from inside OpenMCCellAverageProblem::initialSetup, which you can think of as an extended part of the constructor which we call after all the other objects in your input file have been constructed. My apologies for missing that detail!

To double-check everything, I implemented all the changes you would need as an example here: neams-th-coe/cardinal#671 and confirmed that this works properly.

[WayneX-Wong]

@aprilnovak @GiudGiud I would like to thank you again for your patience and instruction! This solves my problem very well.
Guess I still got to improve my programming skill. Again, thanks so much for your guidance！

[aprilnovak]

Glad it worked! And no problem - the object order-of-construction requires a bit more advanced knowledge of MOOSE (and ideally, that error thrown by MOOSE would be less cryptic). Perhaps @GiudGiud has an idea on how to improve that error

[GiudGiud]

It's tough here it is a getParam that is failing, not a getFunction or a getUserObject which tend to be the errors for order-of-construction related issues.

We already tell the user on a failing getParam which parameter they have defined.
Maybe we could point to Debug/show_actions ? I feel like it would have been instructive here

I already raised this issue to improve this
#23807