Minor fix for NekBinnedPlaneIntegral use in non-dimensional cases

[anshchaube]

Small fix that dimensionalises the _gap_width parameter for use with non-dimensional cases. Without it, the volume integral from the bins gets multiplied by L_ref^3, resulting in incorrect scaling for a userobject that should ultimately yield an area (for an appropriate gap_width).

[moosebuild]

Job Precheck on 9ef4fff 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/cardinal/docs/PRs/882/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 0d1f9b2a9c57c9b0d69d67fda9b226266e07bf6e

[moosebuild]

Job Documentation on 8b8e8c4 wanted to post the following:

View the site here

This comment will be updated on new commits.

[aprilnovak]

shouldn't it be divided by, not multiplied? That way, _gap_thickness is always specified in dimensional form (like the rest of the quantities in NekRSProblem).

[anshchaube]

I have been treating _gap_thickness as non-dimensional when the mesh has been non-dimensionalized. After scaling the mesh in the usr file, I have noticed that treating gap_thickness as dimensional results in errors like:

The following error occurred in the UserObject 'pressure_planar_integral' of type NekBinnedPlaneIntegral.

Failed to map any GLL points to bin 1!

I have had better luck treating it as non-dimensional when the mesh has been non-dimensionalized. However, that means at the end of the process, it needs to be re-dimensionalized so that after dimensionalizeVolume acts on the integral and multiplies it by L_ref^3, the division by L_ref at the end results in a final scaling factor of L_ref^2 for the area. I have verified this by using Nek's internal routines to calculate the same area.

Please let me know if the intended usage is different.

[anshchaube]

I also prefer treating _gap_thickness as non-dimensional when the mesh is non-dimensional because I can get a sense of the gap thickness directly from the Nek output field files.

[aprilnovak]

The convention in Cardinal is that all parameters in the nek.i files are dimensional, though - for instance, if we use a NekPointValue, the point is specified in dimensional form. I am happy to merge this PR, but only if it is consistent with the rest of the accessors.