Tagging parameters and declare knowingly supported & unsupported & incompatible features in input parameters

[GiudGiud]

Reason

Parameter groups are nice but they only order parameters in the documentation. They cant be used to parse input files while inputs are being created to detect incompatible parameters or to restrict the list of objects (for example, only objects working with distributed meshes).

Design

Tagging and features can be separate systems, but could be related through inheritance. (eg a feature is Tag, but not all tags are features).

-params.declareFeatureSupported("distrbuted_meshes"); -params.declareIncompatibleFeatures("distributed_meshes", "stateful_materials", "adaptivity", "repartitioning"); -params.declareParameterForFeature("param1 param2", "feature"); -in documentation: add a feature list paragraph, with links to what each feature means -a default tag could be the app or module. This would help sort objects in GUIs

Tag ideas: The app type For neutronics, we could tag by methods CFEM-diffusion, DFEM, SN, (MOC, MC) etc (@zachmprince @YaqiWang thoughts? or are all objects prefixed or working for all or sorted differently??) On the fluid side, we have an interest for tagging by method (WC, PWC, compressible KT, etc)

Feature supported ideas: distributed meshes higher order variables stateful (depends on the last timestep value) mesh refinement displaced mesh fixed_point_algorithm (incompatible with adaptivity in some capacity?)

Impact

Better parsing of parameters Intelligent GUIs

[YaqiWang]

I am overall supporting this idea. Just extend this with a different design motivated with some similarities discussed in https://github.com/idaholab/moose/issues/19103.

The parameter tagging is kind of like some parameter checking functors. For example,

params.declareParameterForFeature("param1 param2", "distributed_meshes");

can be replaced with

params.addConditionalParam("param1", default_value, distributedMesh, "doc");
params.addConditionalParam("param2", default_value, distributedMesh, "doc");

where distributedMesh is a pre-defined parameter checking functor. These functors requires a MooseApp to access required data such as mesh, equation system, variables, etc, so I am not sure how exact the code syntax will be here.

Also

params.declareIncompatibleFeatures("distributed_meshes", "stateful_materials", "adaptivity", "repartitioning");

can be kept but replaced with parameter check functors as

params.declareIncompatibleFeatures(distributedMesh, !havingStatefulMaterialProps, NonconformingMesh, RepartitionedMesh);

Applications can extend the parameter check functors and use them. We can have a generic parameter dependency checking functor to support https://github.com/idaholab/moose/issues/19103. For Griffin, we can make some parameters conditional with a condition like scheme==CFEM-Diffusion, etc.

Another feature we were thinking of is to support parameter hiding when a condition is met. For example, if a feature is added only for code development, we'd like to make the parameter only in application mode, and it won't be exposed to normal users. This parameter hiding capability can make use of the functors as well. We can have a functor like codeMode==devel.

[YaqiWang]

I will bring this up during our next meeting. I think this can improve the user interface significantly if something along this line is in place.

[GiudGiud]

Well I agree that if we introduce parameter checking functors we can get similar capabilities than tagging, and much more than this while the user is building the input file (online validation of the input file).

Grouping parameters within features would be lower complexity and achieve most of what we want though. It also would allow for parsing the documentation through tags/features

[lindsayad]

Can we decide on a synonym to use for tagging? That already has a defined meaning in the framework and causes some mental juggling when we talk about this

[lindsayad]

Maybe "designating"

[GiudGiud]

well this is user-facing whereas vector tagging is very much developer facing. I m open if there's a good synonym

[lindsayad]

very much developer facing

Users specify extra_vector_tags in their residual object input file blocks in order to modify the vectors their objects feed into