Inheriting from INSFVMomentumAdvection

[joe61vette]

Hello:

In my application, I need to have density(P,T) in a weakly compressible formulation. So, no worries about shock capturing etc.

I would like to base my app on INSFV (or PINSFV). But it seems that I have a problem with inheritance. Namely, in INSFVMomentumAdvection (and related kernels & BCs), the density is given by:

/// Density
const Real & _rho;

and is a required parameter:
params.addRequiredParam("rho", "The value for the density");
params.declareControllable("rho");

and initialized by:
_rho(getParam("rho")),

I can't think of a way to inherit from this and transform _rho to an ADMaterialProperty. Is there some way to accomplish this?

Thanks,
Joe Kelly

[lindsayad]

Hi @joe61vette. It was after charged discussion that we made the design choice to make rho a Real as opposed to a potentially varying material property. We made this choice to actually ensure that users didn't accidentally try to model a compressible problem with incompressible equations. If you actually want to model a compressible problem, I wouldn't recommend trying to work with the INSFV implementation; I would wait instead for the coming CNSFV/PCNSFV work or work off the gitlab fork I've shared with you if you want to get started now. I'm actually quite excited for the CNSFV work where we naturally have on-diagonals in the continuity equation and consequently don't have to use a Rhie-Chow interpolation for velocity in order to avoid the saddle-point problem and the accompanying checkerboard pattern in the pressure field.

[joe61vette]

Thanks Alex. I will take your advice and look at the CNSFV branch. However, my application may fall between CNSFV and INSFV as it would need to consider subcooled liquid (Rhie-Chow needed?) to low-pressure vapor where the effect of gravity head on density is significant.

I am impressed that FVM has been successfully implemented into the MOOSE framework and hope to take advantage of this new capability.

Joe Kelly

[lindsayad]

I would not consider myself a CFD expert, nor an expert on anything really. More a jack-of-all-trades, master-of-none kind of guy 😄 So I, and others, are open to additional implementations and more importantly additional knowledge! Here is my understanding: if we wanted to go with a pressure-based approach to solving (some) (weakly) compressible flows, as opposed to a density-based approach, then what we would be doing fundamentally at a MOOSE implementation level is switching from using density as the nonlinear variable to using pressure as the nonlinear variable. If we do that, then we do indeed need Rhie-Chow again to combat the saddle-point nature of this implementation choice because we no longer have on-diagonals (without Rhie-Chow) in the mass continuity equation. Perhaps naively, this seems like an odd choice, but it must not be so odd because most people do it this way for low Mach number flows. But on the other hand most people are not doing fully coupled solves...but on the gripping hand (a @roystgnr catch-phrase) perhaps the segregated vs. fully-coupled distinction does not even matter. Perhaps I'm making much ado about nothing, and the pressure-based approach for low Mach number flows is truly the best choice even for fully-coupled solves. Anyway if we did elect to support a pressure-based approach to compressible flows, then we could indeed reuse much of the INSFV code. We would have to do some modifications to how we compute the Rhie-Chow interpolated velocity, however.

[joe61vette]

I am not a CFD expert by any means (not even a knowledgeable user). But I have worked in two-phase code development my entire career. Of course, that was finite volume with a staggered grid. Over time, I have developed a marked preference for using primitive variables (P, V, T) rather than conservative ones. A lot of that is based on the phase interaction terms.

Also, my application is for relatively low-speed flows but with density as fn(P, T). I refer to that as "weakly" compressible. It is much simpler than fully compressible (shock capturing etc). So, for now, I will go ahead and work off of INSFV and try to make needed changes in my app. For Rhie-Chow, I am guessing that the necessary changes are because del-dot-V is assumed zero. Of course, that will require me to fully understand the implementation of Rhie-Chow. Lots to learn.

Thanks again for the help,
Joe K

[lindsayad]

So our most used reference for creating INSFV was Moukalled, et. al, "The Finite Volume Method in Computational Fluid Dynamics". You know I'm looking over his compressible flow chapter right now and actually there may be no needed modifications to the way we compute the "Rhie-Chow velocity". Today or over the next few days, I think I should be able to drum up a comparison between a density-based approach and a pressure-based approach that leverages the existing code from INSFV with slight modification. I will try to report back to you ASAP

[lindsayad]

Also @joe61vette if you ever come up with some code that you think is generally useful, we would love to have some external contributors to the module!