View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003981 | OpenFOAM | Bug | public | 2023-05-17 12:30 | 2023-05-17 21:39 |
Reporter | blttkgl | Assigned To | will | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Platform | Unix | OS | Other | OS Version | (please specify) |
Product Version | dev | ||||
Fixed in Version | dev | ||||
Summary | 0003981: Inconsistent NASA polynomial coefficients for air | ||||
Description | I 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 | ||||
Tags | No tags attached. | ||||
|
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 ); } } |
|
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 |
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 |