Specification of air as the ONLY working fluid - massfrac

[SRkumar97]

Hi,
I am trying to run a supersonic boundary layer case over a flat plate, with standard air as the gas.
Now the issue I am facing is wrt the mass fractions and gas_IDs of N2 and O2. I want specify clearly that there is only and only air as the gas.
Now, I found a case which has got N2 and O2 with mass fractions as that of standard air - the Spray-Multijet testcase. Here, the prob_parm.H has the mass fractions stored in the variables Y_N2 and Y_O2 respectively. And the prob.cpp and prob.H files call for these two variables in massfrac[N2_ID] and massfrac[O2_ID] (e.g. - Spray-Multijet and Spray-Conv)

My doubt is, whether these two IDs are pre-defined in PeleC? In certain cases I'm seeing that an additional mass fraction is also specified with a value of absolute 0.0, (e.g. amrex::Real massfrac[NUM_SPECIES] = {0.0}; in Spray-TG) . But I don't understand this additional statement. I am unable to find any value for NUM_SPECIES in the prob_parm.H.

Would be glad if someone could explain all this and inform what is the correct way to specify air as the only working fluid.

I also came across this case involving air -

https://amrex-combustion.github.io/PeleC/validation/validation.html#counter-flow-diffusion-flame

But I am unable to find a case with a matching name in the RegTests folder.

Thanks for reading!

[dmontgomeryNREL]

PelePhysics offers several chemistry mechanisms that include O2. In the GNUmakefile for the Spray-Multijet case, you'll see the line Chemistry_Model := decane_3sp, which points to this specific mechanism in PelePhysics. In the associated mechanism.H file, you'll find three species defined: NC10H22, O2, and N2, each with a pre-defined index ID for the mass fraction. This file also contains the definition for NUM_SPECIES.

If you want to run a case with air, you can set Chemistry_Model := air, then initialize the mass fraction in PeleC using the pre-defined index ID's in the associated mechanism.H file. The air mechanism has two species, O2 and N2. If you only want O2, initialize massfrac[O2_ID] = 1.0 and massfrac[N2_ID] = 0.0, then use corresponding consistent boundary conditions.

[SRkumar97]

Got it, thanks!

[SRkumar97]

Hi, I was able to do my shock simulation, under inviscid assumption using Gamma Law, which is the ideal gas equation for standard air, with R=287 J/Kg-K. Since my case has no kind of reactions and is standard air, Gamma Law works fine. Now I want to run a supersonic boundary layer case. Here, I am happy and well set with using the Gamma Law and Sutherland's law for dynamic viscosity. I am trying to run standard boundary layer flows like in other CFD solvers. However, PeleC doesn't seem to allow this combination of Gamma Law with Sutherland's law. The exec compilation throws an error for this combination. How do I use Gamma Law with Sutherland's law, then?

Note - Here I'm only interested in Sutherland's law for dynamic viscosity. Which will reflect in the values of shear stress. Rest of the transport coefficients are unimportant; can be assumed constant.

[dmontgomeryNREL]

Hi @SRkumar97, have you been able to figure out a work around for your problem yet? PeleC calls PelePhysics for the equations of state, which includes GammaLaw, Fuego, and Soave-Redlich-Kwong, but does not include Sutherland's law.

Will dynamic viscosity be constant in your case? If so, one option is to use a Null chemistry model and manually set the constant transport coefficients in prob.cpp. In the GNUmakefile set:

Eos_Model := GammaLaw
Chemistry_Model := Null
Transport_Model := Constant

Then, in prob.cpp set the dynamic viscosity using Sutherland's law similar to what is done here in the FlowPastCylinder regular test.

[baperry2]

Adding to what @dmontgomeryNREL said, PelePhysics does support Sutherland for the transport model natively, but only when the Eos_Model is set to Fuego. So for air-only simulations, you could use

Eos_Model := Fuego
Chemistry_Model := air
Transport_Model := Sutherland

which would be slightly more expensive but have slightly more accurate thermodynamics than using GammaLaw.

The reason we don't support the combination of Sutherland and GammaLaw natively is the implementation of Sutherland transport involves the CKCPBS function from the Chemistry_Model, which is not implemented for Null chemistry. You could use the native implementation if you replace CKCPBS with eos.TY2Cp and then delete the static assert that raises the error. If you do this consider submitting a PR with the change. See #384.

[SRkumar97]

Thank you very much @baperry2 and @dmontgomeryNREL !

@dmontgomeryNREL I was able to figure out a way, however not exactly the combination I need. Yes, I have decided to use Fuego Law with Transport model as Simple/Sutherland law. However this gives the combination of a thermally perfect gas and varying dynamic viscosity. I am okay to work with, but need to be careful with all BCs and boundary layer profiles (turbinflow).

Yes, @baperry2 I found this way to be computationally more expensive. Since my objective is to simply run LES/Hybrid LES/DNS of non-reacting, general compressible flows, the calorically perfect gas assumption along with varying dynamic viscosity is the perfect combination I need.
As you have put forward, I'll consider editing this function and submit a PR here, if I am successful. Thanks a ton, once again!

Adding to what @dmontgomeryNREL said, PelePhysics does support Sutherland for the transport model natively, but only when the Eos_Model is set to Fuego. So for air-only simulations, you could use

Eos_Model := Fuego
Chemistry_Model := air
Transport_Model := Sutherland

which would be slightly more expensive but have slightly more accurate thermodynamics than using GammaLaw.

The reason we don't support the combination of Sutherland and GammaLaw natively is the implementation of Sutherland transport involves the CKCPBS function from the Chemistry_Model, which is not implemented for Null chemistry. You could use the native implementation if you replace CKCPBS with eos.TY2Cp and then delete the static assert that raises the error. If you do this consider submitting a PR with the change. See #384.

[SRkumar97]

Thank you very much, I am able to correlate and understand whatever you have explained through the suite of testcases.