View Issue Details

IDProjectCategoryView StatusLast Update
0000057OpenFOAM[All Projects] Bugpublic2011-10-27 11:47
Reporteruser36Assigned Tohenry 
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSUbuntuOS Version10.04
Product Version 
Fixed in Version 
Summary0000057: include temperature limitation in function "checkT" in janafThermoI.H
DescriptionBefore 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 ReproduceFeature request.
TagsNo tags attached.

Activities

henry

2010-10-18 16:09

manager   ~0000083

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?

user36

2010-10-18 17:10

  ~0000084

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)

henry

2010-10-18 17:43

manager   ~0000085

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.

user36

2010-10-19 16:09

  ~0000086

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.

henry

2010-10-19 16:41

manager   ~0000087

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?

user36

2010-10-29 16:30

  ~0000106

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?

henry

2010-10-29 16:38

manager   ~0000107

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.

user112

2011-01-10 15:09

  ~0000208

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.

henry

2011-10-27 11:47

manager   ~0000762

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.

Issue History

Date Modified Username Field Change
2010-10-15 10:15 user36 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 user36 Note Added: 0000084
2010-10-18 17:43 henry Note Added: 0000085
2010-10-19 16:09 user36 Note Added: 0000086
2010-10-19 16:41 henry Note Added: 0000087
2010-10-29 16:30 user36 Note Added: 0000106
2010-10-29 16:38 henry Note Added: 0000107
2011-01-10 15:09 user112 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