View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000057 | OpenFOAM | Bug | public | 2010-10-15 10:15 | 2011-10-27 11:47 |
| Reporter | Assigned To | henry | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux | OS | Ubuntu | OS Version | 10.04 |
| Summary | 0000057: include temperature limitation in function "checkT" in janafThermoI.H | ||||
| Description | Before calculating a value for heat capacity, etc. from Janaf-polynomials, the function checkT is called. This function checks if the given temperature-parameter is within the valid temperature range of the respective polynomial. If not it produces a fatal error and stops the solver. I think many people are familiar with the "attempt to use janafThermo<equationOfState> out of temperature range " error message. Especially when calculating combustion cases,this error happens quite often, since "on the way" from initialized state to converged solution some combustion models temporarily overpredict the reaction rate. In order to increase stability, it would be favorable not to produce a FatalError but to limit the temperature to THigh or TLow. This should of course be accompanied by some warning message but should not stop the solver. One may argue that temperature limitation makes the next time step invalid, however in combustion calculation it is also often desirable to perform steady state calculations where this does not represent a problem. For steady-state combustion cases, temperature limiting is a common (and necessary) practice. An alternative implementation could be limiting "Test" in specieThermoI.H, however a change in janafThermoI.H would takle the problem at the core. | ||||
| Steps To Reproduce | Feature request. | ||||
| Tags | No tags attached. | ||||
|
|
Generally we find that "attempt to use janafThermo<equationOfState> out of temperature range " indicates a serious problem, often to do with inappropriate boundary conditions and forcibly clipping the temperature to allow the code to continue does not solve the problem but rather is a method to generate a VERY large number of warning messages before the eventual demise of the run. However, as you say, there are circumstances where clipping the temperature may allow the run to reach a physical state but I am not sure that this behavior should be the default. Perhaps we sould add a switch to the top-level controlDict to control the clipping/warning/error behavior of the thermodynamics. If it were switched to clipping would you want to receive a warning message for every cell and every time-step for which clipping is applied? |
|
|
Hi Henry, thanks for having a look at this! I would prefer to have a warning message for every time-step. If I want to see where the clipping occurs, I can use a post-processing tool and have a look at the time-step's data to see where the temperature equals the max or min value (with paraview, cellSet, etc.). The place I would naturally look for the option to limit the temperature would be in thermophysicalProperties. Maybe it would also make sense to define there explicitly an upper/lower temperature limit (as opposed to look for the janaf polynomial's upper and lower bound which might be different for every species; the latter is the case e.g. in the thermo.dat of the GRI-3.0 mechanism) |
|
|
The point in the code where the clipping would be applied is at the "specie" level and hence has no information about time, space fields etc. so it is not clear how the warning could be switched so that it occurs only once per time-step but it could be set so that it only occurs once per run. The temperature limits on the polynomials relate to the accuracy and range of the fit, if this information is not use for the clipping how would consistency be guaranteed? The user would have to check the polynomial data to ensure that the clip-levels chosen are consistent. Maybe it would be sensible to use the narrower of the ranges from the two specifications. Also the user input in thermophysicalProperties would have to be region-dependent because different regions might use different thermodynamics. However the "specie" level has no knowledge of the region in which the functions are being applied so ideally the limits should be stored at the "specie" level which is difficult to arrange convenient input for. We will consider this further with the plan to include some kind of temperature limiting functionality in the next release. |
|
|
The most consistent way is indeed to use the polynomials upper/lower temperature for clipping. An example where more narrow limits would be necessary is steady state combustion: combustion models are developed for a physical range where combustion reactions usually take place. The standard "therm.dat" is defined with Tmax=5000 K, which is clearly beyond this range. So I might want to introduce a lower Tmax, e.g. 3000 K, to make my combustion model applicable. My suggestion for a possible implementation would be another instance of specieThermo that can be used alternatively to janafThermo. This could be some sort of "janafThermoLimitedT", which has changes in the constructor (Tlow_ is assigned the higher value from janaf-Tmin and the value in thermophysicalProperties; Thigh_ the opposite) and in checkT (clipping instead of FatalError). If regions are defined as in chtMultiReaionFoam tutorial from 1.6.x(I have no experience multi region cases so far) then I could select the behaviour per region by changing, say: hsPsiMixtureThermo<homogeneousMixture<sutherlandTransport<specieThermo<janafThermo<perfectGas>>>>> to hsPsiMixtureThermo<homogeneousMixture<sutherlandTransport<specieThermo<janafThermoLimitedT<perfectGas>>>>> The unsolved problem then would be the per time-step warning message. You suggested a once-per-run message and I think that would be a sufficient solution. I don't know if this is all feasible but it might be a quite simple solution. |
|
|
If the temperature limits are to be supplied with the polynomial coefficients as they are with the janafThermo what is the advantage of creating a new janafThermoLimitedT class over introducing clipping directly into janafThermo and set the temperature limits appropriately? |
|
|
I thought that a separate janafThermoLimitedT would solve the problem that the "specie" level has no knowledge about the region it is in(cf. your post #85). Since different regions can use different thermodynamics, the question "to clip or not to clip" would be handled at creation time of the thermodynamic object. Which major obstacles do you see in implementing a temperature limitation one way or another and is there a possibility for me to contribute? |
|
|
I don't see the problem in adding clipping into janafThermo or introducing janafThermoLimitedT with the limits being those supplied with the polynomial coefficients but I still do not see the advantage of introducing janafThermoLimitedT over adding clipping directly into janafThermo. We will consider the options with the aim of providing this functionality in the next release. |
|
|
Hi all! I think it will be better to have a warning for each time step in which clipping occurs. This is useful for steady-state combustion cases, where reduced kinetic schemes overpredict temperatures and clipping will certainly occur for one iteration at least. The frequency of clippings throughout iterations would be an indication that some tweaking on Cp values (i.e. overestimation) is almost necessary, because complete kinetics would go through dissociations near adiabatic temperatures. |
|
|
I have now completed the implementation of temperature clipping using the Tlow_ and Thigh_ provided by JANAF. The interface allows clipping within other specieThermo types but at the moment it is not clear that this is necessary for those currently provided. This functionality will be available in the next version of OpenFOAM we release. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-10-15 10:15 |
|
New Issue | |
| 2010-10-15 22:35 | henry | Assigned To | => henry |
| 2010-10-15 22:35 | henry | Status | new => assigned |
| 2010-10-18 16:09 | henry | Note Added: 0000083 | |
| 2010-10-18 17:10 |
|
Note Added: 0000084 | |
| 2010-10-18 17:43 | henry | Note Added: 0000085 | |
| 2010-10-19 16:09 |
|
Note Added: 0000086 | |
| 2010-10-19 16:41 | henry | Note Added: 0000087 | |
| 2010-10-29 16:30 |
|
Note Added: 0000106 | |
| 2010-10-29 16:38 | henry | Note Added: 0000107 | |
| 2011-01-10 15:09 |
|
Note Added: 0000208 | |
| 2011-10-27 11:47 | henry | Note Added: 0000762 | |
| 2011-10-27 11:47 | henry | Status | assigned => resolved |
| 2011-10-27 11:47 | henry | Resolution | open => fixed |
