View Issue Details

IDProjectCategoryView StatusLast Update
0003981OpenFOAMBugpublic2023-05-17 21:39
Reporterblttkgl Assigned Towill  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformUnixOSOtherOS Version(please specify)
Product Versiondev 
Fixed in Versiondev 
Summary0003981: Inconsistent NASA polynomial coefficients for air
DescriptionI have been having some stability issues with a moving piston-valve setup we've built, where we use a pureMixture mixture model with properties of air taken from the $FOAM_TUTORIALS folder. Upon closed examination, we noticed that the total enthalpy values calculated from the highCpCoeffs provided for air do not align with reference data we create using Cantera. While we do not have high temperatures in our setup, this discrepancy probably affects our enthalpy during PIMPLE iterations, causing instabilities especially during mesh mapping.

In an attached figure, you can find a figure that demonstrates the total enthalpy calculated from: 1) Air polynomials under the tutorials folder, 2) Air enthalpy calculated from Cantera using GRI3.0 chemical mechanism for a 21% O2 72% N2 mixture, 3) Our polynomial fit on this curve (provided in attachment thermo.foam)

It is probable that these polynomials are taken from literature, fitted for aerodynamics in mind with non-optimal high-end temperature values. We wanted to provide this fix to ensure that somebody else would not make the same mistake and take them directly from the tutorials.


As far as I can tell, following tutorials include the polynomial coefficients or air with high end temperature issues:

modules/multicomponentFluid/parcelInBox 
modules/multicomponentFluid/verticalChannel
modules/multicomponentFluid/verticalChannelLTS
modules/multicomponentFluid/verticalChannelSteady
modules/multiphaseEuler/bubbleColumnEvaporating
modules/multiphaseEuler/bubbleColumnEvaporatingReacting
modules/multiRegion/CHT/heatExchanger




TagsNo tags attached.

Activities

blttkgl

2023-05-17 12:30

reporter  

thermo.foam (1,010 bytes)   
air
{
	specie
	{
		nMoles 	 1;
		molWeight 	28.850974789915966;
	}

	thermodynamics
	{
		Tlow		280.0;
		Thigh		3000.0;
		Tcommon		1000.0;
		lowCpCoeffs	(	3.3930026535747237 0.000544363265919478 -1.2462171865247582e-06 2.655786547234184e-09 -1.3553770014160103e-12 -1029.281194688508 4.432585085246043  );
		highCpCoeffs	(	3.058087944777262 0.001336341358091655 -4.733942923568294e-07 7.386531757164599e-11 -3.342049296115616e-15 -972.8898463747888 6.09033606555187  );
	}

	transport 
	{
		As	1.6853581850699974e-06;
		Ts	227.72854078370528;
		muLogCoeffs<8>	(	-19.094045417186987 2.4952967284765233 -0.24894941228543024 0.011161918789250793 0 0 0 0  );
		muCoeffs<8>	(	6.844014345229418e-06 4.428679680308672e-08 -9.601952301960428e-12 1.2717326861093204e-15 0 0 0 0  );
		kappaLogCoeffs<8>	(	-1.952920633976932 -2.071823307685607 0.4373285624461873 -0.02205532908672101 0 0 0 0  );
		kappaCoeffs<8>	(	0.005106415762562572 7.337053843887705e-05 -9.769902593478969e-09 8.944137817148215e-13 0 0 0 0  );
	}

}

thermo.foam (1,010 bytes)   
enthalpy_comparison.png (49,490 bytes)   
enthalpy_comparison.png (49,490 bytes)   

will

2023-05-17 21:39

manager   ~0013018

Thanks for the report. Yes, the data in those cases is clearly unreliable. We also have the fits in `etc/thermoData/thermoData`, but these are optimised for high temperature combustion, and the fit for air starts to breaks down under 300K. Yours is better at the lower temperatures, and only diverges beyond 3000K. On balance, I think your data is the better compromise. I think evaporation at 300K-ish is a more likely use case than acetylene combustion. Pushed here:

https://github.com/OpenFOAM/OpenFOAM-dev/commit/a1c85e0771e6f26c1d4ebebaa8ba619ae83e0566

Issue History

Date Modified Username Field Change
2023-05-17 12:30 blttkgl New Issue
2023-05-17 12:30 blttkgl File Added: thermo.foam
2023-05-17 12:30 blttkgl File Added: enthalpy_comparison.png
2023-05-17 21:39 will Assigned To => will
2023-05-17 21:39 will Status new => resolved
2023-05-17 21:39 will Resolution open => fixed
2023-05-17 21:39 will Fixed in Version => dev
2023-05-17 21:39 will Note Added: 0013018