Let us control the pressure action

[GiudGiud]

@jessecarterMOOSE can you look at the caveat in the documentation file and confirm it works for you?

It is fairly unconventional. @joshuahansel can you please take a look too?

We have 3 other options at least:

• make the "enable" parameter private in the BCs object (when we create them from the action) so it can only be set from controlling the action. Therefore it no longer is surprising that they are all on / off at the same time
  EDIT: no current APIs to do that
• create three enable parameters in the action and forward those to each BC. Seems not very useful
• use the control_tag parameter only (no enable in the Action). The control tag is shared between all 3 BCs created, so <control_tag>/enable should be the way to refer to all 3 parameters together. control_tags are pretty clever but I'm fairly sure they are even less used than Controls

Whichever solution we find here might end up being deployed largely for Physics. So we can control a Physics all at once

[moosebuild]

Job Documentation, step Docs: sync website on 59e325e wanted to post the following:

View the site here

This comment will be updated on new commits.

[moosebuild]

Job Coverage, step Generate coverage on 59e325e wanted to post the following:

Framework coverage

	e193a3	#29603 59e325
	Total	Total	+/-	New
Rate	85.25%	85.25%	-0.00%	-
Hits	108024	108023	-1	0
Misses	18686	18687	+1	0

Diff coverage report

Full coverage report

Modules coverage

Solid mechanics

	e193a3	#29603 59e325
	Total	Total	+/-	New
Rate	84.97%	84.98%	+0.01%	100.00%
Hits	28392	28404	+12	19
Misses	5022	5022	-	0

Diff coverage report

Full coverage report

Full coverage reports

Reports

• framework
• chemical_reactions
• combined
• contact
• electromagnetics
• external_petsc_solver
• fluid_properties
• fsi
• functional_expansion_tools
• geochemistry
• heat_transfer
• level_set
• misc
• navier_stokes
• optimization
• peridynamics
• phase_field
• porous_flow
• ray_tracing
• rdg
• reactor
• richards
• scalar_transport
• solid_mechanics
• solid_properties
• stochastic_tools
• thermal_hydraulics
• xfem

This comment will be updated on new commits.

[moosebuild]

Job GCC min debug on dfdaab3 : invalidated by @GiudGiud

unrelated timeout

[jessecarterMOOSE]

I think I'm fine with your implementation @GiudGiud . I don't see a reason (or if it even makes sense) why someone would turn off one of the BC's (disp_x, _y, or _z) created by a Pressure BC and not the others. So I would be in favor of preventing the user from doing that in the first place (your first bullet point)

About your documentation note, you say that "enable" has to be explicitly set in the input file but I do not see that in the test case.

[joshuahansel]

Yeah, we have problem with controlling components - they need to "forward" the controllable parameters. We do this as with Component::connectObject:

  MooseObjectParameterName alias("component", component_name, component_param, "::");
  MooseObjectParameterName obj_param_full(obj_params.get<std::string>("_moose_base"), obj_name, obj_param);
  _app.getInputParameterWarehouse().addControllableParameterAlias(alias, obj_param_full);

However, I've noticed that trying to control Components/component_name/component_param in the input file doesn't work; instead you have to do component/component_name/component_param, so that part isn't great. If we could fix that, that would be the best solution to this problem.

@GiudGiud I will go ahead and see if I can figure out something here.

[joshuahansel]

Ok, so I found that this was the solution to my problem at least:

    connectControllableParams("rho", obj_class_name, obj_name, "rho");

Does connectControllableParams not work in your situation? It looks like you wrote this method, so I'm guessing there's an issue.

[GiudGiud]

I don't recall writing this.
Does not seem to work here

test:pressure.3D: *** ERROR ***
test:pressure.3D: Unable to locate secondary parameter with name BoundaryCondition/Pressure_Side1_0/enable

seems the syntax isn't right. I think the true syntax is Pressure/BoundaryCondition/...
and it would not be BCs. It s because it uses the "moose_base" to form the syntax instead of the actual syntax

[GiudGiud]

@jessecarterMOOSE ok I adapted the message. If there is no reason to control them separately then imo what we have here is fine.

[joshuahansel]

What you have seems simple and effective. I might try moving components to use this approach too.

[joshuahansel]

I just tried your same approach with components, but it has no effect. I don't understand how yours works. When you do

params.set<bool>("theparam) = getParam<bool>("theparam");

it's creating a copy of the initial value getParam<bool>("theparam"), not a reference, right?

[GiudGiud]

I'll double check.
Maybe we need a new routine for references

[GiudGiud]

" connectControllableParams("rho", obj_class_name, obj_name, "rho");"

is the correct solution here. Thanks @joshuahansel !
I'll deploy this to Physics at some point.

[jessecarterMOOSE]

Could you generalize this? Seems useful for other actions that create kernels etc.

[GiudGiud]

I think so for physics / actions that create equations.
Maybe the action warehouse should return parameters with already the connection between the two enable Boolean parameter (as soon as it exists for the Action, it always exists for the MooseObject)

[joshuahansel]

I would vote against any sort of automatic parameter connection. I think in most cases you'd want a specific Physics parameter like enable_kernelA.

I think the only thing to improve would be to somehow connect when someone tries to control a parameter that doesn't actually do anything (like a Physics parameter that the developer forgot to connect to an object parameter), but I'm not sure how we'd detect that (without just using special logic for Physics etc. in the control system), so maybe not.

[GiudGiud]

. I think in most cases you'd want a specific Physics parameter like enable_kernelA.

This could be great but I m not sure we can do if we have some sort Physics-wide "enable" (that ties the Physics enable to all the kernels, and probably just the kernels). I dont know that connectControllableParam can handle 2 separate connections for the same parameter

I think the only thing to improve would be to somehow connect when someone tries to control a parameter that doesn't actually do anything (like a Physics parameter that the developer forgot to connect to an object parameter), but I'm not sure how we'd detect that (without just using special logic for Physics etc. in the control system), so maybe not.

This would be great. I think it might be possible if we:

• form a list of all parameters being controlled
• check if any are part of the Physics
• check if they are all "connected" to an actual object parameter

[joshuahansel]

Ok, so I guess you mean Physics task that does the check, rather than some logic that lives in the control system. Yeah I think that's good. It doesn't need to be in this PR, but at least make an issue for it.

[GiudGiud]

ok created #29687

[GiudGiud]

ok took care of that last test failure I think. imo people need to stop inheriting classes but not their parameters...