Fixes PrecursorAction with velocity functions, and supports higher order precursor variable initialization

[smpark7]

Fixes #183. Fixes #265.

Description

PrecursorAction allows users to define their velocity values for delayed neutron precursor advection using constants, mathematical functions, or MOOSE variables. However, using velocity functions had limited scope due to bugs described in #183. With this PR, PrecursorAction will fully support modeling precursor flow with velocity functions (in line with existing functionality with constant or coupled velocity values).

This PR also extends support for modeling precursor variables with higher (>0) order discontinuous variables.

Changes

• New PrecursorAction Enum input parameter velocity_type to indicate whether the velocity components are constant, function, or variable
  • Replaces the old constant_velocity_values bool-type parameter
• New SideFunctionWeightedIntegralPostprocessor to calculate precursor outflow at the outlet when using velocity functions
• Edits in PrecursorAction:
  • Check whether users provided the correct type of velocity parameters
  • Initialize precursor advection kernels when using higher order variables
  • Initialize penalty boundary conditions to suppress unphysical numerical oscillations at the inlet near the wall
  • Correctly calculate the outflow precursor concentration when using velocity functions
• New & updated tests for precursor flow modeling with velocity functions and first order variables.
• Update squirrel submodule for PostprocessorVelocityFunctionInflowBC, VelocityFunctionConservativeAdvection, & PostprocessorPenaltyDirichletBC objects required in this bugfix.
• Update MOOSE submodule for general updates
• Fix tests in moltres/problems/2021-cnrs-benchmark/phase-0 which were checking the wrong input file

Impact

• Users can now use velocity functions when modeling precursor flow with core reentry
• Users can now use higher (>0) order precursor variables
• New features/updates from the MOOSE submodule update

[nglaser3]

This PR looks good! I've added a few small comments throughout.

[nglaser3]

This Postprocessor block does not appear to be adding anything to this input file.

[nglaser3]

This Postprocessor block does not appear to be adding to this input file.

[nglaser3]

There does not appear to be a test added to the test suite to check this Postprocessor, should there be a test added for this? Or was this meant to be included in the sub_1st.i or sub_func.i tests in the empty Postprocessors block?

[smpark7]

Good catch. I'll add a test similar to the current tests for SideWeightedIntegralPostprocessor

[nglaser3]

This file has a lot of repeated if statements checking the same parameters in each equation. Instead of having a series of if-else statements in each equation, would an overarching switch() statement on the _velocity_type Enum be possible to help with segregation of the three possible types? Or would that make this file absurdly long and unnecessarily separated?

[samgdotson]

I think this is a valid requested change, @nglaser3! Also, should there be an “else” block? Are you sure all cases are covered? Perhaps adding one could help with debugging in the future (e.g. if a feature isn’t implemented yet). I noticed at least 1 missing else statement. Just some thoughts.

[smpark7]

This file has a lot of repeated if statements checking the same parameters in each equation.

I agree but it's with good reason. The functions in the file are currently separated by kernel type (e.g., addTimeDerivative, addPrecursorDecay). I think this separation by "physics" makes sense for understanding what each function does, albeit at the cost of having so many if statements to support 3 different velocity types. If we group the if blocks together and refactor the code, each velocity-related "physics" will require a function for each velocity type. In that sense, @nglaser3 you're right that the file will become "absurdly long and unnecessarily separated" and more difficult to parse as a human.

I like the switch case statement syntax but it's annoying to use here because we'll need a separate Enum definition alongside the current MooseEnum. It's extra code without any programming/computational benefit.

Also, should there be an “else” block? Are you sure all cases are covered?

@samgdotson The velocity_type input parameter only accepts one of the three MooseEnum values listed in velocity_type. Otherwise MOOSE does not accept the input value and spits out an error. Moltres will never reach the else block. At this point I can't think of any potential velocity type that doesn't fall under constant, function, or variable

[katyhuff]

@smpark7 , what's the status of this one?

[smpark7]

I need to address nathan's comments and rerequest reviews. I'll get on it this week