1D flame tolerance bug

[GoogleCodeExporter]

What steps will reproduce the problem?

There is a bug which affects the specification of time-stepping and steady 
state tolerances for all one-dimensional flame simulations. The problem is an 
implementation issue that can be tracked back to the initialization routine for 
the Newtonian solver used for the steady-state and transient calculations. The 
tolerances used by the Newton solver depend on a switching mechanism which is 
supposed to set the member variable "m_rdt'' in the Domain1D class equal to 
zero when the steady state solution is to be obtained. This is not being done 
when the solver switches from time-stepping to the steady-state calculation.

What is the expected output? What do you see instead?

Steady state tolerances have no bearing on the calculation. Right now, 
time-stepping tolerances are being used in the criteria for convergence for 
both the sudo-temporal and steady-state calculations. This will lead to 
solutions that are poorly converged if the user has specified loose 
time-stepping tolerances.

What version of the product are you using? On what operating system?

This problem is found in all versions.

Please provide any additional information below.

I fixed this bug in my own source in the following way:

The first step was to add a new member function to the public access level of 
the OneDim class which overloads the function OneDim::setSteadyState() by 
creating a new function of the same name in the file.

This function uses the same method used to switch over to the transient 
settings in OneDim::initTimeInteg(). It reads in the solution vector and cycles 
through these objects setting the member variable m_rdt = 0 using the member 
function Domain1D::setSteadyMode().

The overloaded function is called in OneDim::timeStep().

Original issue reported on code.google.com by watso...@gmail.com on 27 Dec 2010 at 1:48

[GoogleCodeExporter]

Original comment by yarmond on 28 May 2011 at 12:06

• Changed state: Accepted

[GoogleCodeExporter]

Fixed in r1392.

Original comment by yarmond on 10 Apr 2012 at 3:13

• Changed state: Fixed