Small PIDTransientControl enhancement

[jthano]

closes #26742

[moosebuild]

Job Documentation on 3263f4e wanted to post the following:

View the site here

This comment will be updated on new commits.

[GiudGiud]

There's two changes here, but only one is tested

Add to documentation:

How to use in a transient

...

How to use in a steady solve

...
!listing

Add an input for steady solves if you want to enable this

[jthano]

There's two changes here, but only one is tested

Add to documentation:

How to use in a transient

...

How to use in a steady solve

... !listing

Add an input for steady solves if you want to enable this

Okay, I'll look into this more. I mentioned Steady executioner in the warning message because the original mooseError message said If using a Steady Executioner, add a minimum number of Picard iterations and comment this error. Do you know what the use case was that inspired the original message? I could just change my mooseWarning to a mooseError and not mention the Steady Executioner?

[GiudGiud]

Do you know what the use case was that inspired the original message? I

the use case is that you can consider doing a picard multiapp iteration with the PIDController active.
Didnt it start as a mooseError? Are you planning to use this with a steady executioner

[jthano]

Do you know what the use case was that inspired the original message? I

the use case is that you can consider doing a picard multiapp iteration with the PIDController active. Didnt it start as a mooseError? Are you planning to use this with a steady executioner

No in my use case the problem will be a transient (with a custom Executioner that is not Transient) and I won't see this warning message. I didn't understand the original mooseError message that well. It seems that if you suggest to the user to comment out an error and recompile for their use case, then it should be a warning, as in the usage they want is advanced and non-typical but supported to some extent. I can add a test for using this with a Steady executioner or I can just change my mooseWarning back to a mooseError with a message similar to the original one. I like the idea of trying to add a test with a Steady executioner if the original intention of the object was to support that as an advanced use case.

[GiudGiud]

I did not have time to make sure it worked with Steady so I added an error instead of a warning.
It's not super supported. The P ok, the Integral and the derivative are meh / ill-defined with a steady executioner.

[jthano]

I did not have time to make sure it worked with Steady so I added an error instead of a warning. It's not super supported. The P ok, the Integral and the derivative are meh / ill-defined with a steady executioner.

Okay, I'll change it back to a mooseError then. I think that is the best solution.

[moosebuild]

Job Coverage on 3263f4e wanted to post the following:

Framework coverage

	519d81	#26743 3263f4
	Total	Total	+/-	New
Rate	85.21%	85.21%	+0.00%	90.91%
Hits	99626	99628	+2	10
Misses	17292	17291	-1	1

Diff coverage report

Full coverage report

Modules coverage

Coverage did not change

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_properties
• stochastic_tools
• tensor_mechanics
• thermal_hydraulics
• xfem

This comment will be updated on new commits.

[jthano]

I changed the warning to an error. Let me know if you agree with the message. I think if someone tries to use the object with a Steady executioner, they will know based on the error message to open an issue and ask for that to be supported or do it themselves.

[GiudGiud]

looks good.