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 bb4a56b wanted to post the following:

View the site here

This comment will be updated on new commits.

[moosebuild]

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

Framework coverage

	d93971	#29603 dfdaab
	Total	Total	+/-	New
Rate	85.25%	85.25%	-0.00%	-
Hits	108003	108002	-1	0
Misses	18680	18681	+1	0

Diff coverage report

Full coverage report

Modules coverage

Solid mechanics

	d93971	#29603 dfdaab
	Total	Total	+/-	New
Rate	84.95%	84.96%	+0.00%	90.91%
Hits	28318	28325	+7	10
Misses	5015	5016	+1	1

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