Capability deprecation in nalu-wind

[rcknaus]

Here's a short list of things that we can consider getting rid of in nalu-wind. Not really meant as a full list or anything---I just want to start off the discussion.

---

Percept-based, dynamic mesh adaptation: What is it: conformal refinement of meshes given a chosen error estimator during a simulation

• Reason for deleting: unstructured, in-situ adaptation never really proven to be effective in practice. Not really tested.
• Reason against: Theoretically reduces amount of computational work

Two-dimensional support What is it: mesh data structures that are truly two-dimensional

• Reason for deleting: Two-dimensional simulations can still be performed by extruding two elements thick. Deleting reduces the codebase substantially by allowing for the removal of the 2D master elements.
• Reason against: The cost of 2D simulations would be at least twice that of a true 2D implementation

Participating media radiation What is it: An equation system describing how thermal radiation is emitted and reabsorbed in a fluid

• Reason for deleting: it's a specialized thermal heat transfer model

• Reason against deleting: Perhaps could be a model for humid air heating in the sun for very large ABL simulations?

  Flamelets What is it: A flame microstructure model for combustion processes

  • Reason for deleting: Hopefully nothing is on fire in wind energy
  • Reason against deleting: the pure scalar mixing equation used by flamelets, "MixtureFractionEquationSystem", can be useful for flow visualization.

Mass Fraction What is it: An equation describing multicomponent flows with potentially differential diffusion evolve

• Reason for deleting: We don't need multicomponent mixtures for any problems as far as I know, much less differential diffusion.
• Reason against deleting: Unclear.

Conjugate Heat Transfer (CHT) What is it: Coupled heat transfer between a fluid and a solid

• Reason for deleting: Not an important effect for wind energy
• Reason against deleting: Unclear.

Realms What is it: a conceptualization of different physics or intents

• Reason for deleting: not really used except for interpolating solutions between different meshes
• Reason against deleting: It's a current capability allowing multi physics coupling

[sayerhs]

@rcknaus Thanks for starting this list.

I agree with deprecating Percept-based mesh adaptivity (already removed in NaluCFD/Nalu), PMR, CHT, and Flamelets stuff. It will be there in the git-history if we need to dig these up.

Regarding 2D, most of the element types have been migrated to NGP. However, it would be great to be able to make ndim a compile time constexpr in several places.

Regarding Mass/Mixture fraction, what are your thoughts on the whole offshore wind-wave simulation needs and the use of these equation systems for that purpose?

Our FSI pathway by coupling with OpenFAST doesn't use multiple-realms, so Realms is just a glorified std::vector that could easily live in TimeIntegrator.

[rcknaus]

For offshore, I don't know the plan, but saying it's some level-set/volume of fluid variant then the solution process is different enough that we probably just want it to have its own equation system anyway.

[rcknaus]

Most of these things have been removed and removing the remaining set is of dubious benefit.