June 2025 News

NekRS Wrapping Changes

We have performed a major refactor of how data transfers are performed between NekRS and MOOSE. Instead of data transfers being detected automatically (which was error-prone and opaque as to what coupling modes were enabled), users must now explicitly list the data transfers their application is using. The advantages of the new syntax include:

Users will have an explicit understanding (and control) over what data transfers are happening. Users will control the names of the auxiliary variables and postprocessors that Cardinal creates (instead of hard-coded names being used) as well as being able to mix-and-match transfers.
All of the NekRS problem classes (originally named NekRSProblem, NekRSStandaloneProblem, and NekRSSeparateDomainProblem) have been collapsed into a single class, NekRSProblem. This allows users to now interchange all data transfers simultaneously; notably, this now allows users to couple NekRS with systems-level T/H, while also using any of the data transfers which formerly were exclusively possible with NekRSProblem (parameter perturbations with the stochastic tools module, conjugate heat transfer, neutronics feedback, and fluid-structure interaction).

All users are required to update your input files. A few examples are given below. Please contact the Cardinal developer team if you need assistance with updating your files. To omit all data transfers (i.e. the equivalent of the prior NekRSStandaloneProblem class), simply swap with NekRSProblem.

Conjugate Heat Transfer

To update Conjugate Heat Transfer (CHT) cases, your input files will transition from the old syntax:


[Problem]
  type = NekRSProblem
[]

to the new syntax:


[Problem]
  type = NekRSProblem

  [FieldTransfers]
    [avg_flux]
      type = NekBoundaryFlux
      direction = to_nek
      usrwrk_slot = 0
      postprocessor_to_conserve = flux_integral
    []
    [temp]
      type = NekFieldVariable
      direction = from_nek
      field = temperature
    []
  []
[]

A slightly shorter syntax can also now be used if you want to use the new defaults for variable names (whatever the name of the object is). Below will create a variable named flux for the heat flux transfer and a postprocessor named flux_integral. The temperature variable will be named temperature.


[Problem]
  type = NekRSProblem

  [FieldTransfers]
    [flux]
      type = NekBoundaryFlux
      direction = to_nek
      usrwrk_slot = 0
    []
    [temperature]
      type = NekFieldVariable
      direction = from_nek
    []
  []
[]

Volumetric Heat Sources

To update volumetric coupling cases, your input files will transition from the old syntax:


[Problem]
  type = NekRSProblem
[]

to the new syntax:


[Problem]
  type = NekRSProblem

  [FieldTransfers]
    [heat_source]
      type = NekVolumetricSource
      direction = to_nek
      usrwrk_slot = 0
      postprocessor_to_conserve = source_integral
    []
    [temp]
      type = NekFieldVariable
      direction = from_nek
      field = temperature
    []
  []
[]

A slightly shorter syntax can also now be used if you want to use the new defaults for variable names (whatever the name of the object is). Below will create a variable named source for the heat source transfer and a postprocessor named source_integral. The temperature variable will be named temperature.


[Problem]
  type = NekRSProblem

  [FieldTransfers]
    [source]
      type = NekVolumetricSource
      direction = to_nek
      usrwrk_slot = 0
    []
    [temperature]
      type = NekFieldVariable
      direction = from_nek
    []
  []
[]

Fluid-Structure Interaction

To update fluid-structure interaction cases, your input files will transition from the old syntax:


[Problem]
  type = NekRSProblem
[]

to the new syntax:


[Problem]
  type = NekRSProblem

  [FieldTransfers]
    [disp]
      type = NekMeshDeformation
      direction = to_nek
      usrwrk_slots = '0 1 2'
    []
    [temp]
      type = NekFieldVariable
      direction = from_nek
      field = temperature
    []
  []
[]

Uncertainty Quantification

To update forward Uncertainty Quantification (UQ) cases, your input files will transition from the old syntax:


[Problem]
  type = FEProblem
[]

[UserObjects]
  [scalar1]
    type = NekScalarValue
  []
[]

[Postprocessors]
  [view_scalar1]
    type = NekScalarValuePostprocessor
    userobject = scalar1
  []
[]

to the new syntax:


[Problem]
  type = FEProblem

  [ScalarTransfers]
    [scalar1]
      type = NekScalarValue
      usrwrk_slot = 0
      direction = to_nek
      output_postprocessor = view_scalar1
    []
  []
[]

[Postprocessors]
  [view_scalar1]
    type = Receiver
  []
[]

Performance Improvements for Particle Transport on CAD Geometry

We added two optional dependencies to Cardinal: Double-Down and Embree. Embree is a high-performance single-precision ray tracing library and Double-Down is a wrapper library which enables double-precision ray-triangle intersection tests in Embree. This addition results in substantial gains in single-thread performance and threaded scalability for particle transport on triangulated CAD geometries compared to native MOAB raytracing. Cardinal can be built with both of these libraries by exporting ENABLE_DOUBLE_DOWN=yes. At present, these capabilities are disabled by default due to compilation issues on some (but not all) platforms - if you experience difficulties building Cardinal with Double-Down and Embree please post on the Github discussion page.

NekRS Wrapping Changes
Performance Improvements for Particle Transport on CAD Geometry