Order matters in input file for UserObjects

[brianmoose]

Description of the enhancement or error report

I was looking at modules/phase_field/tests/reconstruction/1phase_evolution.i In the UserObjects block, if ebsd is defined after tracker (which references ebsd) then running gives the error Unable to find user object with name 'ebsd' Andrew seemed to think this was a bug.

[dschwen]

Yeah, that'd be a bug.

[permcody]

Damn. We need a ticket for that. In general, all bindings need to be lazy so that input file order doesn't matter. On Mon, Oct 17, 2016 at 8:40 AM Daniel Schwen notifications@github.com wrote:

Yeah, that'd be a bug.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/idaholab/moose/issues/7879#issuecomment-254226951, or mute the thread https://github.com/notifications/unsubscribe-auth/AC5XIFul4S33zLnzT-YhYLwvdlx0KTfUks5q04jcgaJpZM4KYsX9 .

[brianmoose]

This could be duplicate of #6254

[brianmoose]

This also seems to happen with Functions. Reordering ff_1 or ff_2 in test/tests/bcs/function_dirichlet_bc/function_dirichlet_bc_test.i to after forcing_func causes the same issue.

[jessecarterMOOSE]

Yeah, I reported what led to #6254 a while back. I'm hazy now on the specifics, but it appeared that order didn't matter among a specific user object type (Elemental, Nodal, General), but since they are constructed or initialized in a certain order (e.g. Elemental before General), I couldn't put a General before Elemental in the input file, unless I used a pointer instead of a reference and initialized it outside the constructor. That pretty much forced me to use pointers since I have elemental UO's that depend on general UO's and vice-versa so I couldn't find an order that worked. That might also hold in this case for UO's depending on PP's? I'm not familiar with the grain tracking stuff...

[permcody]

That sounds right. This might be tricky to fix up the UserObjectInterface because of the templated call. One of us will just have to dig in and figure it out.

[YaqiWang]

Thumbs up to @lindsayad !

[lindsayad]

I don't know why I closed this. This fixes evaluation ordering but doesn't fix issues with respect to use of getUserObject in a user object constructor, e.g. there are still construction order issues

[lindsayad]

Lazy binding won't work in the case that one user object actually uses the other during the construction phase. But then the question is whether we can perform dependency resolution at the parser stage? Is that a path we want to go down? I believe I saw @loganharbour talking about this in slack

[loganharbour]

But then the question is whether we can perform dependency resolution at the parser stage? Is that a path we want to go down? I believe I saw @loganharbour talking about this in slack

We can. I don't think this would be a difficult task.

Is the name of the UO that you depend on known via input parameters?

[YaqiWang]

Is the name of the UO that you depend on known via input parameters?

Probably. Even not, we can add a function that validParams can call to insert dependency.

[loganharbour]

Is the name of the UO that you depend on known via input parameters?

Probably. Even not, we can add a function that validParams can call to insert dependency.

How? I don't understand how you plan on doing this with something that is stateless.

[YaqiWang]

The simplest solution is to let user add a parameter depends_on or call a function like dependingUOs() which accepts the parameter name containing depending uo names.