Add method for setting input parameter unit for purposes of documentation

[cticenhour]

Reason

This change is intended to address corrective action CA 2021-1199 for BlackBear/Grizzly (and other MOOSE-based application to which a similar CA applies) and provide a new capability to framework and application developers who with to provide more context regarding intended units for a given parameter. This is not intended to provide automatic unit conversion for input parameters (but could likely be used as the API to tweak further in the future).

Design

Create setDocoUnit and getDocoUnit methods for setting a unit in the object source code and getting it for use in other code or, in this case, in the JSON output for use in MooseDocs. MooseDocs infrastructure to display this new parameter metadata should also be constructed in accordance with the other parameter metadata already presented.

Impact

New documentation for intended units in calculations will improve software quality. This is not a simulation enhancement but a user/developer quality-of-life one.

[cticenhour]

@bwspenc Here's a candidate implementation for you to try. This PR still needs finalization with respect to API and output metadata naming, as well as tests and some documentation, but I wanted to get it in your hands to try out.

An example of usage for ADMatDiffusion is given by:

InputParameters
ADMatDiffusion::validParams()
{
  auto params = ADMatDiffusionBase<Real>::validParams();
  params.addClassDescription(
      "Diffusion equation kernel that takes an isotropic diffusivity from a material property");
  params.setDocUnit("diffusivity", "m^2 / s");
  return params;
}

which then results in

I am considering changing the metadata label to "Assumed Units", but would welcome feedback.

[loganharbour]

If we do this, I think that we also need to use the MooseUnit system somehow to also keep track of this unit so that it can properly be converted to other units if the primary units are declared in another way.

[cticenhour]

I have gone back and forth on this, and @dschwen and I spoke about it previously. He can chime in with thoughts now that MooseUnit is in the framework. I am open to a re-write to integrate this into MooseUnit, but then that would open up the door to propagating units throughout the framework, which we've always stepped up to the line for but never quite committed to.

[cticenhour]

Making sure that otherwise declared units are consistent (for error-checking if nothing else) would be a good thing here, I think, at minimum.

[loganharbour]

Making sure that otherwise declared units are consistent (for error-checking if nothing else) would be a good thing here, I think, at minimum.

I agree. I just want to make sure that we design it s.t. it has the unit integration in mind for the future, hopefully not backing us out

[moosebuild]

Job Precheck on 053a050 wanted to post the following:

Your code requires style changes.

A patch was auto generated and copied here
You can directly apply the patch by running, in the top level of your repository:

curl -s https://mooseframework.inl.gov/docs/PRs/27352/clang_format/style.patch | git apply -v

Alternatively, with your repository up to date and in the top level of your repository:

git clang-format 97af19c98a76c47db2b4157c4e73c28f68f45595

[moosebuild]

Job Documentation on 6afa1c7 wanted to post the following:

View the site here

This comment will be updated on new commits.

[moosebuild]

Job Coverage on 6afa1c7 wanted to post the following:

Framework coverage

	636a45	#27352 6afa1c
	Total	Total	+/-	New
Rate	85.04%	85.04%	-0.00%	77.78%
Hits	105635	105648	+13	14
Misses	18582	18587	+5	4

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_mechanics
• solid_properties
• stochastic_tools
• thermal_hydraulics
• xfem

Warnings

• framework new line coverage rate 77.78% is less than the suggested 90.0%

This comment will be updated on new commits.

[moosebuild]

Job Documentation, step Docs: sync website on 3d98b17 wanted to post the following:

View the site here

This comment will be updated on new commits.

[moosebuild]

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

Framework coverage

	999039	#27352 3d98b1
	Total	Total	+/-	New
Rate	85.05%	85.04%	-0.00%	77.78%
Hits	106016	106029	+13	14
Misses	18641	18646	+5	4

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_mechanics
• solid_properties
• stochastic_tools
• thermal_hydraulics
• xfem

Warnings

• framework new line coverage rate 77.78% is less than the suggested 90.0%

This comment will be updated on new commits.

[cticenhour]

Our internal discussions on this current design suggest there is a lot more to be done here in order to integrate this system into that of MooseUnit and use it for more than just documentation. We've decided that this is beyond the scope of work for this particular PR, given time constraints on SQA deliverables, and will proceed with reviewing and merging this version of the API and documentation integration. Future work will integrate MooseUnit features.

Tagging @bwspenc for a review.

[bwspenc]

Looks good to me. I made a couple of comments on really minor stuff that you can leave alone if you prefer.