You can open another bug report with a feature request ;)

You can re-open the bug report I think (scroll down the page).

Nope, only the original poster can re-open his/her own bug report. And I've reported before about this and... see for yourself: http://www.openfoam.com/mantisbt/view.php?id=228 :D

Hmm. I add this as a reason to prefer bugzilla to mantis ;-)

Hi Alberto and Daniel,

I think mantis has an option for this... but I'm not 100% certain about this :(

By the way, to close the loop on this thread, a proper solution has been implemented for the issue that lead to the creation of this thread! Seen here: http://www.openfoam.com/mantisbt/view.php?id=382#c950 - the aforementioned commit is this one: https://github.com/OpenFOAM/OpenFOAM...e6cf8aa2c9bf39

Apparently the solution was a lot simpler than I first deduced... I thought there would be far more logical/cyclic issues with these variables, but I didn't look deep enough into an actual solution :rolleyes:

Best regards,
Bruno

It's good to see Henry's revision.

To change deltaT, "Go to controlDict" is a user's most natural selection.

What would be the reason for this
 

Hi Bruno, Daniel, Albreto and others,

I created tempPimpleFoam solver adding T field into basic pimpleFoam. And I tested it for pitzDaily tutorial case. But when I run the actual case it gave me the following error massage after running few iterations.

deltaT = 1.58835e-65
--> FOAM Warning :
From function Time::perator++()
in file db/Time/Time.C at line 1010
Increased the timePrecision from 145 to 146 to distinguish between timeNames at time 0.00166302
Time = 0.001663021666070488464861387711835050140507519245 147705078125



I could see that deltaT is keep on reducing and timePrecision value was adjusting in every timestep.

Sorry I can not attach the test case since the forum file size is very small.

Any idea would be appreciated.
Best regards,
Suranga.

similar problem
 

Hey guys,

I'm getting super small time steps:
circa 1x10^-8 when I've set my deltaT to 0.001

Anyone know why its doing this?

Also does anyone have any best practice tips for getting a fireFoam simulation to run a bit faster? for example can you get by with a course mesh? any parameters in fvSchemes or fvSolution that you would recommend?

I'm aware LES solvers take a long time to solve but mine is taking a bit too long I think.

This is my fvSolution file:

/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: dev |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object fvSolution;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

solvers
{
"(rho|rhoFinal)"
{
solver PCG;
preconditioner DIC;
tolerance 1e-6;
relTol 0;
};

p_rgh
{
solver GAMG;
tolerance 1e-6;
relTol 0.1;
smoother GaussSeidel;
};

p_rghFinal
{
$p_rgh;
tolerance 1e-6;
relTol 0;
};

ph_rgh
{
$p_rgh;
}


"(U|Yi|k|h)"
{
solver PBiCGStab;
preconditioner DILU;
tolerance 1e-6;
relTol 0.1;
nSweeps 1;
};

"(U|Yi|k|h)Final"
{
$U;
tolerance 1e-6;
relTol 0;
};

Ii
{
solver GAMG;
tolerance 1e-4;
relTol 0;
smoother symGaussSeidel;
maxIter 1;
nPostSweeps 1;
}

G
{
solver PCG;
preconditioner DIC;
tolerance 1e-04;
relTol 0;
}

}

PIMPLE
{

nNonOrthogonalCorrectors 2;
pRefPoint (1 0 0.25);
pRefValue 84437;


momentumPredictor yes;
nOuterCorrectors 1;
nCorrectors 2;
nNonOrthogonalCorrectors 0;

hydrostaticInitialization yes;
nHydrostaticCorrectors 5;
}

relaxationFactors
{
equations
{
"(U|k).*" 1;
"(CH4|O2|H2O|CO2|h).*" 1;
}
}

// ************************************************** *********************** //



Followed by fvSchemes:

/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: dev |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

ddtSchemes
{
default Euler;
}

gradSchemes
{
default Gauss linear;
}

divSchemes
{
default none;

div(phi,U) Gauss LUST grad(U);
div(phi,K) Gauss linear;
div(phi,k) Gauss limitedLinear 1;
div(phi,Yi_h) Gauss multivariateSelection
{
O2 limitedLinear01 1;
C12H24 limitedLinear01 1;
N2 limitedLinear01 1;
H2O limitedLinear01 1;
CO2 limitedLinear01 1;
h limitedLinear 1;
};
div(((rho*nuEff)*dev2(T(grad(U))))) Gauss linear;
div(Ji,Ii_h) Gauss upwind;
}

laplacianSchemes
{
default Gauss linear corrected;
}

interpolationSchemes
{
default linear;
}

snGradSchemes
{
default corrected;
}


// ************************************************** *********************** //

I have a similar question about time control when using overPimpleDyMFoam in OpenFOAM v2006. It's weird that I lose the data for the last few time steps when I try to write out data every 10 time steps.

I tried different combinations but none of them work.

Option 1:


Option 2:

Option 2:


Here is the complete controlDcit for the first one:
Here is the time directories (first column) generated. The second column is the time difference calcualted by hand (current - previous time step). It shows the deltaT is correct. But the last one is 0.0072988 which should be 0.0073502 as set in controlDict. That means the data for the last 5 time steps are not outputed. But when I the log file shows the solver goes through all the time steps including Time = 0.00733992.

By the way, the delataT in uniform/time shows consistent with that in controlDict.
I hope Bruno, Alberto or some others can have a look at my problem. I have been stuck in this problem for a few days. I will add more information if needed.

After posting, I just found I changed the endTime during the run incorrectly which made the endTime not a multiple of writeInterval though it is a multiple of deltaT. That's why the data were not outputed.

Sorry about that!