`MeshScaling` should be spatially variable to properly account for changes in mesh resolution.

[hyungyukang]

Omega currently applies spatially uniform Del2 and Del4 MeshScaling values, which are hard-coded as 1.0 in HorzMesh.cpp:

//------------------------------------------------------------------------------
// Set mesh scaling coefficients for mixing terms in momentum and tracer
// equations so viscosity and diffusion scale with mesh.
void HorzMesh::computeMeshScaling() {

   OMEGA_SCOPE(o_MeshScalingDel2, MeshScalingDel2);
   OMEGA_SCOPE(o_MeshScalingDel4, MeshScalingDel4);

   // TODO: implement mesh scaling by cell area, only no scaling
   // option for now
   parallelFor(
       {NEdgesAll}, KOKKOS_LAMBDA(int Edge) {
          o_MeshScalingDel2(Edge) = 1.0;
          o_MeshScalingDel4(Edge) = 1.0;
       });

   MeshScalingDel2H = createHostMirrorCopy(MeshScalingDel2);
   MeshScalingDel4H = createHostMirrorCopy(MeshScalingDel4);

} // end computeMeshScaling

These scaling factors directly affect the horizontal Del2 and Del4 viscosity/diffusion coefficients. For example, MeshScalingDel2 is multiplied into the Del2 tendency in TendencyTerms.h:

      for (int KVec = 0; KVec < KLen; ++KVec) {
         const I4 K = KStart + KVec;
         const Real Del2U =
             ((DivCell(ICell1, K) - DivCell(ICell0, K)) * DcEdgeInv -
              (RVortVertex(IVertex1, K) - RVortVertex(IVertex0, K)) *
                  DvEdgeInv);

         Tend(IEdge, K) +=
             EdgeMask(IEdge, K) * ViscDel2 * MeshScalingDel2(IEdge) * Del2U;
      }
   }

MeshScalingDel2 and MeshScalingDel4 should be spatially variable to properly account for changes in mesh resolution. Without this, simulations on variable-resolution meshes can be more vulnerable to numerical noise and model instability.

[cbegeman]

I checked the defaults for MPAS-O for variable resolution meshes, and these are the lines of code that would be called, but the comment implies that this is not the preferred implementation. Do we need to discuss the preferred implementation here or @hyungyukang did you already settle this? https://github.com/E3SM-Project/E3SM/blob/e508436e4542882b0b06910b9542c376d4b5f841/components/mpas-ocean/src/shared/mpas_ocn_mesh.F#L1804-L1817

[hyungyukang]

@cbegeman , the method is still the default in MPAS-O because config_hmix_use_ref_cell_width is disabled by default. Although the inline comment says that it "should become defunct", I am not aware of a better alternative at this point. I think this would be a good time to discuss the preferred implementation.

[xylar]

I don't think we want to do anything involving the meshDensity field. Some tools define meshDensity to be all ones while others use this odd definition:
https://github.com/MPAS-Dev/MPAS-Tools/blob/281c669f315fd906d886f57fe708faa00098b29a/conda_package/mpas_tools/ocean/inject_meshDensity.py#L77
Either way, it relies on the field being set in the expected way in the horizontal mesh file, which makes little sense to me. I think the Omega default should be the equivalent of:
https://github.com/E3SM-Project/E3SM/blob/e508436e4542882b0b06910b9542c376d4b5f841/components/mpas-ocean/src/shared/mpas_ocn_mesh.F#L1785-L1802
and the alternative should be a constant value.

[hyungyukang]

@xylar , I agree with you. It seems that meshDensity could cause confusion in the future.

I was just wondering if there is a reason why MPAS-O does not use the config_hmix_use_ref_cell_width approach, especially if Omega’s default should use that approach.

[cbegeman]

I also agree. It's hard for me to envision issues with the config_hmix_use_ref_cell_width approach; it's consistent with what other modeling groups use.

[xylar]

@hyungyukang, I'm also really surprised to see that config_hmix_use_ref_cell_width isn't the default. This may not be intentional.