Using Vector Variables with User-Defined Number of Components in MOOSE

[Silverwing747]

Check these boxes if you have followed the posting rules.

• Q&A Navier Stokes is the most appropriate category for my question
• I have consulted the posting Guidelines on the Discussions front page
• I have searched the Discussions forum and my question has not been asked before
• I have searched the MOOSE website and the documentation does not answer my question
• I have formatted my post following the posting guidelines (avoid screenshots if possible, triple back quotes before/after pasted text, etc)

Question

Hello everyone, and Happy New Year!

In the MOOSE NS Module, I noticed that density, temperature, and velocity are typically declared as independent variables. I understand this approach provides greater flexibility. However, for tightly coupled systems of PDEs, such as the compressible Navier-Stokes equations, this requires repeatedly declaring couplings for nearly every kernel, material property, etc., which seems suboptimal.

I noticed that MOOSE supports LAGRANGE_VEC variables, where the components are inherently coupled. This got me wondering: is it possible for a user to define a vector variable with DIM+2 components (e.g., velocity vector + density + temperature) so that these variables are coupled by default? This would allow implementing the compressible Navier-Stokes equations in their compact form, simplifying variable transformations.

I looked through the forums and example codes but couldn’t find anyone doing this. Is this approach feasible in MOOSE? If so, what would be the pros and cons? How would it effect computational efficiency? Some drawbacks I can think of is reduced efficiency in automatic differentiation, less code flexibility, but there may be others I haven’t considered.

I’d love to hear your thoughts and experiences!

Additional information

No response

[ngrilli]

@Silverwing747 I think what you are asking for is similar to the phase field model for grain growth, see:
https://github.com/idaholab/moose/blob/next/modules/phase_field/src/kernels/ACGrGrBase.C
A vector of coupled variables is passed to a kernel with coupledValues
then you can have a look at this:
https://github.com/idaholab/moose/blob/next/modules/phase_field/src/kernels/ACGrGrPoly.C
for the calculation of residual, Jacobian and off-diagonal Jacobian using the vector variable.
The function coupledComponents provides the number of components of the vector,
so it's not given a priori, but user-defined in the input file.

[GiudGiud]

The output of material properties cannot be changed to Lagrange properties because we do not compute material properties at nodes, but rather at quadrature points.

The problem with nodes is that they may be shared by elements from multiple subdomains. This could mean that multiple materials provide different definitions of the same material property for each subdomain around the node.

[Silverwing747]

The materials are computed once for the residual evaluation and once for the Jacobian evaluation. By once, I mean once per element and quadrature point. There is an option in the Executioner to compute the residual and Jacobian together, which is mostly used in combination with automatic differentiation.

Hello Guillaume,

I was wondering if you could point me to a website or example code that demonstrates how to signal the executioner to compute the Jacobian and Residual together. So far, I haven’t been able to find any relevant resources.

I noticed that the Kernel class includes a public function, virtual void computeResidualAndJacobian() override;, and some applications, like INSFVFluxKernel, seem to utilize it. However, I couldn’t find anything in the executioner related to enabling or controlling this functionality.

[GiudGiud]

See the executioner parameters

https://mooseframework.inl.gov/source/executioners/Steady.html

It s called residual_and_jacobian_together

[Silverwing747]

Hello Guillaume,

Thank you so much for your support! So far, this approach works well. The only downside is that if you have terms that need to be applied with the gradient of the test function later, you’ll need to store high-dimensional arrays for the residual and Jacobian of those terms (similar to KernelGrad).

I think solving this issue might require applying the test function at the material object, which I believe could be challenging to implement.

[GiudGiud]

I think solving this issue might require applying the test function at the material object, which I believe could be challenging to implement.

Materials can retrieve a variables which in its base classes has routines to retrieve test and shape functions. So it's not impossible, just unconventional