Questions about meshing in Cardinal

[Ethan-xj]

Hello everyone! I know I can use Cubit or Gmsh to generate the mesh which I need. But is there any existed functions which can generate coarse mesh, like subchannel-scale?

Ethan

[aprilnovak]

Are you looking for a mesh on which to solve the Navier-Stokes equations, or a mesh on which to just output subchannel-averaged quantities?

[Ethan-xj]

To solve the Navier-Stokes equations. I want to perform CFD calculations at the whole-core level, but using conventional mesh partitioning would result in a huge number of meshes. Therefore, I intend to reduce the mesh count by employing coarse mesh method.

[aprilnovak]

If you are looking to use a subchannel method, the Pronghorn MOOSE application includes a subchannel solver (a full list of the MOOSE-based thermal-hydraulics applications is here: https://mooseframework.inl.gov/applications/thermal_hydraulics.html). Note that a subchannel mesh is not a typical "mesh" in the sense that there aren't tet/hex/etc. elements (it's really more a collection of finite volume nodes which have a very specific meaning on what the governing equations represent). The MOOSE Navier-Stokes module also contains a porous media method, a different type of coarse mesh method which could also be a candidate and for which you would instead generate the usual types of unstructured meshes.

For general-purpose meshing, the MOOSE reactor module can be used to generate meshes (of customizable resolution) for pin bundles (and many other types of geometry). We have some wrapper scripts in Cardinal that build some specific geometries by calling the MOOSE reactor module.

Let me know if you had something else in mind!

[Ethan-xj]

Thank you for replying! And I want to ask if I can create the mesh using Gmsh and manually convert it to the .re2 format? Btw, do you know how to open .re2 format mesh files?
The last thing is that I found that the srf_7pin case cannot be computed properly, and the following error occurs:

nek0: 
nek0: Time Step 11, time = 0.0055, dt = 0.0005
nek0: Sending heat flux to NekRS boundary 1, 2...
nek0: [boundary 1, 2]: Normalizing total NekRS flux of 1708.97 to the conserved MOOSE value of 205650
nek0: 
nek0: 
nek0: *** ERROR ***
nek0: The following error occurred in the object "MOOSE Problem", of type "NekRSProblem".
nek0: 
nek0: Flux normalization process failed! NekRS integrated flux: 206460 MOOSE integrated flux: 205650.
nek0: There are a few reason this might happen:
nek0: 
nek0: - You have a mismatch between the NekRS mesh and the MOOSE mesh. Try visualizing the
nek0:   meshes in Paraview by running your input files with the --mesh-only flag.
nek0: 
nek0: - Your tolerances for comparing the re-normalized NekRS flux with the incoming MOOSE
nek0:   flux are too tight. If the NekRS flux is acceptably close to the MOOSE flux, you can
nek0:   try relaxing the 'normalization_abs_tol' and/or 'normalization_rel_tol' parameters
nek0: 
nek0: - You forgot to send a flux VARIABLE to NekRS, in which case no matter what you try to
nek0:   normalize by, the flux in NekRS is always zero.
nek0: 
nek0: - If you set 'conserve_flux_by_sideset = true' and nodes are SHARED by boundaries
nek0:   (like on corners between sidesets), you will end up renormalizing those shared nodes
nek0:   once per sideset that they lie on. There is no guarantee that the total imposed flux
nek0:   would be preserved.
nek0: 
nek0: 
nek0: 
nek0: *** ERROR ***
nek0: The following error occurred in the object "MOOSE Problem", of type "NekRSProblem".
nek0: 
nek0: Flux normalization process failed! NekRS integrated flux: 206460 MOOSE integrated flux: 205650.
nek0: There are a few reason this might happen:
nek0: 
nek0: - You have a mismatch between the NekRS mesh and the MOOSE mesh. Try visualizing the
nek0:   meshes in Paraview by running your input files with the --mesh-only flag.
nek0: 
nek0: - Your tolerances for comparing the re-normalized NekRS flux with the incoming MOOSE
nek0:   flux are too tight. If the NekRS flux is acceptably close to the MOOSE flux, you can
nek0:   try relaxing the 'normalization_abs_tol' and/or 'normalization_rel_tol' parameters
nek0: 
nek0: - You forgot to send a flux VARIABLE to NekRS, in which case no matter what you try to
nek0:   normalize by, the flux in NekRS is always zero.
nek0: 
nek0: - If you set 'conserve_flux_by_sideset = true' and nodes are SHARED by boundaries
nek0:   (like on corners between sidesets), you will end up renormalizing those shared nodes
nek0:   once per sideset that they lie on. There is no guarantee that the total imposed flux
nek0:   would be preserved.
nek0: 
nek0: 
nek0: 
nek0: *** ERROR ***
nek0: The following error occurred in the object "MOOSE Problem", of type "NekRSProblem".
nek0: 
nek0: Flux normalization process failed! NekRS integrated flux: 206460 MOOSE integrated flux: 205650.
nek0: There are a few reason this might happen:
nek0: 
nek0: - You have a mismatch between the NekRS mesh and the MOOSE mesh. Try visualizing the
nek0:   meshes in Paraview by running your input files with the --mesh-only flag.
nek0: 
nek0: - Your tolerances for comparing the re-normalized NekRS flux with the incoming MOOSE
nek0:   flux are too tight. If the NekRS flux is acceptably close to the MOOSE flux, you can
nek0:   try relaxing the 'normalization_abs_tol' and/or 'normalization_rel_tol' parameters
nek0: 
nek0: - You forgot to send a flux VARIABLE to NekRS, in which case no matter what you try to
nek0:   normalize by, the flux in NekRS is always zero.
nek0: 
nek0: - If you set 'conserve_flux_by_sideset = true' and nodes are SHARED by boundaries
nek0:   (like on corners between sidesets), you will end up renormalizing those shared nodes
nek0:   once per sideset that they lie on. There is no guarantee that the total imposed flux
nek0:   would be preserved.
nek0: 
Abort(1) on node 2 (rank 2 in comm 0): application called MPI_Abort(MPI_COMM_WORLD, 1) - process 2
nek0: 
nek0: 
nek0: *** ERROR ***
nek0: The following error occurred in the object "MOOSE Problem", of type "NekRSProblem".
nek0: 
nek0: Flux normalization process failed! NekRS integrated flux: 206460 MOOSE integrated flux: 205650.
nek0: There are a few reason this might happen:
nek0: 
nek0: - You have a mismatch between the NekRS mesh and the MOOSE mesh. Try visualizing the
nek0:   meshes in Paraview by running your input files with the --mesh-only flag.
nek0: 
nek0: - Your tolerances for comparing the re-normalized NekRS flux with the incoming MOOSE
nek0:   flux are too tight. If the NekRS flux is acceptably close to the MOOSE flux, you can
nek0:   try relaxing the 'normalization_abs_tol' and/or 'normalization_rel_tol' parameters
nek0: 
nek0: - You forgot to send a flux VARIABLE to NekRS, in which case no matter what you try to
nek0:   normalize by, the flux in NekRS is always zero.
nek0: 
nek0: - If you set 'conserve_flux_by_sideset = true' and nodes are SHARED by boundaries
nek0:   (like on corners between sidesets), you will end up renormalizing those shared nodes
nek0:   once per sideset that they lie on. There is no guarantee that the total imposed flux
nek0:   would be preserved.
nek0: 
Abort(1) on node 1 (rank 1 in comm 0): application called MPI_Abort(MPI_COMM_WORLD, 1) - process 1
Abort(1) on node 3 (rank 3 in comm 0): application called MPI_Abort(MPI_COMM_WORLD, 1) - process 3

Ethan

[aprilnovak]

Hi @Ethan-xj -

• Yes, you can create a mesh with Gmsh and then convert it to re2 format using the gmsh2nek utility in Nek5000. Instructions for how to access this utility can be found here: https://cardinal.cels.anl.gov/nek_tools.html.

• Unfortunately there is not a way to visualize re2 files directly -- but if you have an re2 file, you can convert it into a MOOSE mesh and then view that (this mesh does not have contiguous nodes, as it was created in Cardinal just for the sake of passing data, not an actual solve; but you can do this to visualize).

# a file named input.i
[Mesh]
  type = NekRSMesh
  order = FIRST
  volume = true
[]

cardinal-opt -i input.i --mesh-only

This will make a file named input_in.e which you can visualize in Paraview.

• Did you change anything about the sfr_7pin case? I just reran it locally and cannot reproduce those errors.