Time is always zero

kian · September 24, 2007, 17:04

Hello OpenFoam Users,

I have 1.4.1, compiled with single precision.
I noticed that when I use a deltaT lower than 1.0E-05, it is basically regarded as zero. In other words, time is always zero!
I checked the deltaT.value() in the code (sonicFoam), and it contains the correct value.

Any advice is appreciated,

Kian

kian · September 25, 2007, 00:16

I compiled with double precision, and the problem is gone now.

mattijs · September 25, 2007, 14:53

See Time.C around line 620.

The problem in single precision is that there are only 6 significant digits. There is some truncation in operator++ to reach time 0 exactly which is probably too strict for your case.

kian · September 26, 2007, 11:15

In the code segment you pointed to (the ++ operator), time is set to
value() + deltaT_
then it is forced to zero if its value is less than 10*SMALL or 1E-5, perhaps for aesthetics?!

I can't understand why it is not forced to zero in double precisions, when your deltaT is say 1E-8?

kian · September 26, 2007, 11:24

OK, I was wrong about SMALL being 1E-6 in double precision, that value is for single precision.

The actual value of SMALL is 1E-15 in dp.

I wanted to get rid of that if statement, but I'm going to stick with the dp version instead, since it is better tested.

September 24, 2007, 17:04	Hello OpenFoam Users, I hav	#1
kian New Member Kian Mehravaran Join Date: Mar 2009 Location: London, U.K Posts: 22 Rep Power: 17	Hello OpenFoam Users, I have 1.4.1, compiled with single precision. I noticed that when I use a deltaT lower than 1.0E-05, it is basically regarded as zero. In other words, time is always zero! I checked the deltaT.value() in the code (sonicFoam), and it contains the correct value. Any advice is appreciated, Kian

September 25, 2007, 00:16	I compiled with double precisi	#2
kian New Member Kian Mehravaran Join Date: Mar 2009 Location: London, U.K Posts: 22 Rep Power: 17	I compiled with double precision, and the problem is gone now.

September 25, 2007, 14:53	See Time.C around line 620.	#3
mattijs Senior Member Mattijs Janssens Join Date: Mar 2009 Posts: 1,419 Rep Power: 26	See Time.C around line 620. The problem in single precision is that there are only 6 significant digits. There is some truncation in operator++ to reach time 0 exactly which is probably too strict for your case.

September 26, 2007, 11:15	In the code segment you pointe	#4
kian New Member Kian Mehravaran Join Date: Mar 2009 Location: London, U.K Posts: 22 Rep Power: 17	In the code segment you pointed to (the ++ operator), time is set to value() + deltaT_ then it is forced to zero if its value is less than 10*SMALL or 1E-5, perhaps for aesthetics?! I can't understand why it is not forced to zero in double precisions, when your deltaT is say 1E-8?

September 26, 2007, 11:24	OK, I was wrong about SMALL be	#5
kian New Member Kian Mehravaran Join Date: Mar 2009 Location: London, U.K Posts: 22 Rep Power: 17	OK, I was wrong about SMALL being 1E-6 in double precision, that value is for single precision. The actual value of SMALL is 1E-15 in dp. I wanted to get rid of that if statement, but I'm going to stick with the dp version instead, since it is better tested.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Is there a way to write the time step size, time a	may	FLUENT	6	November 22, 2009 12:52
Time step in time explicit solver	Simon	FLUENT	1	August 5, 2009 11:32
Long time CHT transient simulation time step....	JP	CFX	0	May 9, 2008 04:36
autosave at flow time with adaptive time stepping	Ybes	FLUENT	0	November 3, 2007 13:32
Relation of computational time step with real time	Salman	Main CFD Forum	2	August 3, 2005 15:13