CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Bugs (https://www.cfd-online.com/Forums/openfoam-bugs/)
-   -   Strange rhoCentralFoam behavior after restart... (https://www.cfd-online.com/Forums/openfoam-bugs/93934-strange-rhocentralfoam-behavior-after-restart.html)

vkrastev October 31, 2011 10:55

Strange rhoCentralFoam behavior after restart...
 
1 Attachment(s)
Hi all,
well I don't know if this can be considered a real bug, but I've noticed a really strange (and highly undesirable) behavior of the rhoCentralFoam solver when a simulation is stopped and then restarted from the stop point...A brief description of my case: I'm trying to get some aerodynamic torque evaluations on a 2D simple throttle valve geometry; the flow is pressure driven (fixed pressures at inlet and outlet of the duct containing the valve) and till now I'm getting good overall results (except for some strange little pressure/velocity oscillations, which seem to be peculiar of the rhoCentralFoam solver). The fact is that being the runs quite long (it tooks about 2 days to simulate 0.1 s of physical time), I need sometimes to stop-and-restart the simulations at some point, but... :eek: when I first restarted a simulation and took a look on the torque plot from the forces function I got a very sharp discontinuity! I mean, If run the case from t=0 to, let's say, t=0.1 s I get some torque plot; otherwise, if I stop the original run at, let's say t=0.05 s, and then restart it, the plot re-starts from a completely different point and thus the final torque value (at t=0.1 s) is also very different! I'm sure that is not a problem of the forces function, because I've also checked the pressure distribution around the valve and there is indeed a sudden change immediately after the restart!
Any opinion about this matter? Is this a problem encountered also by someone else?
For more clearness a picture of a torque plot with two different restarts is attached below

Regards

V.

deepsterblue October 31, 2011 11:11

Since this run is transient, I would imagine that there's an "old-time" value that is required in the computation, but isn't written out to disk. Usually, fields, etc tend to be initialized with the current value if an old-time value was not found. You might want to check on that...

vkrastev October 31, 2011 11:49

Quote:

Originally Posted by deepsterblue (Post 330164)
Since this run is transient, I would imagine that there's an "old-time" value that is required in the computation, but isn't written out to disk. Usually, fields, etc tend to be initialized with the current value if an old-time value was not found. You might want to check on that...

Hi Sandeep, and thanks for the reply. Sorry for my persistence, but could you clarify what do you mean with "old" and "current" values?

V.

deepsterblue October 31, 2011 11:58

Old - when referring to the state of the field in the previous time-step.
Current - when referring to the state of the field in the current time-step.

If you're dealing with fields, that is. I might be wrong too, since I would expect torque to be instantaneous, and wouldn't normally associate it with an old-time value...

It's just that when I see restart issues like this, the first thing to check would be whether old-time values are being stored / retrieved appropriately from disk..

vkrastev October 31, 2011 13:34

Quote:

Originally Posted by deepsterblue (Post 330177)
Old - when referring to the state of the field in the previous time-step.
Current - when referring to the state of the field in the current time-step.

If you're dealing with fields, that is. I might be wrong too, since I would expect torque to be instantaneous, and wouldn't normally associate it with an old-time value...

It's just that when I see restart issues like this, the first thing to check would be whether old-time values are being stored / retrieved appropriately from disk..

Ok, thanks once again. Actually you made me think about a possible explanation for this behavior: the problem could be localized not in the old-values reading, but in the data storage precision (the torque values here are pretty small, thus prone to fluctuations with very small pressure variations over the valve surface). I'm doing some tests now increasing a lot the write precision, so let's see what happens...

V.

alberto November 1, 2011 18:46

Store data in binary format to see if it makes a difference.

ASCII format makes it easier to edit the case, but binary is recommended not to lose information. Additionally, you can convert from one into the other.

vkrastev November 2, 2011 05:25

Quote:

Originally Posted by alberto (Post 330365)
Store data in binary format to see if it makes a difference.

ASCII format makes it easier to edit the case, but binary is recommended not to lose information. Additionally, you can convert from one into the other.

Thanks, I'll try it.

V.

vkrastev November 2, 2011 14:48

1 Attachment(s)
Well, I'm starting to worry seriously about this restart matter...I've selected binary as output and increased the write precision a lot, but the result is absolutely not encouraging (see the image attached below)...Could this be reported as a bug of the rhoCentralFoam solver or I'm missing something else? Any help/idea would be really appreciated

Regards

V.

alberto November 2, 2011 15:06

I would report :)

vkrastev November 2, 2011 18:30

Quote:

Originally Posted by alberto (Post 330496)
I would report :)

Reported! (let's see what happens)

vkrastev November 8, 2011 14:06

Bug fixed
 
Hi all,
there was actually a problem in the updating of the flux phi, which has been fixed today with the following OF-2.0.x commit

commit dc17e722ab2a9539775eec59650e6dc0e7eb9360

The bug is present both in OF-1.7.x and OF-2.0.x families, and can be fixed in the same way also for 1.7.x. I think it is important to know for all users that if not fixed, that bug can lead to significantly erroneous results using rhoCentralFoam, as an error seems to propagate through time because of the incorrect phi update (see this page for more details http://www.openfoam.com/mantisbt/view.php?id=332 )

Best

V.

alberto November 8, 2011 15:15

Thanks for the update!

vkrastev November 8, 2011 17:00

Quote:

Originally Posted by alberto (Post 331251)
Thanks for the update!

You are welcome! :)

praveen November 8, 2011 22:15

Quote:

Originally Posted by vkrastev (Post 331239)
Hi all,
there was actually a problem in the updating of the flux phi, which has been fixed today with the following OF-2.0.x commit

commit dc17e722ab2a9539775eec59650e6dc0e7eb9360

The bug is present both in OF-1.7.x and OF-2.0.x families, and can be fixed in the same way also for 1.7.x. I think it is important to know for all users that if not fixed, that bug can lead to significantly erroneous results using rhoCentralFoam, as an error seems to propagate through time because of the incorrect phi update (see this page for more details http://www.openfoam.com/mantisbt/view.php?id=332 )

Best

V.

But what was the bug ? Looking at the changes

https://github.com/OpenFOAM/OpenFOAM...oCentralFoam.C

I fail to understand what the bug was ?

vkrastev November 9, 2011 05:02

I think (but I'm not sure of it) that the problem was a redundance in the phi declaration between the createFields.H and the rhoCentralFoam.C files

Regards

V.

laurensvd November 10, 2011 03:43

A beginners question (but googling for commit doesnt seem to work :D), how do you 'commit' such an update? Is it related to svn (my it-administrator doesnt allow this)? If its just the rhoCentralFoam.C or rhoCentralFoam.H that is changed, could someone post this change so I can manually fix it if commit is no option? If the only change is the deletion of this one line of code for phi and adding the other as mentioned above, forget I asked something ;)

praveen November 10, 2011 03:54

Though there was a redundancy, I dont think phi was the problem. Time step does not seem to have been properly set for restarted cases. The below fix is also required for the same bug that vkrastev reported

https://github.com/OpenFOAM/OpenFOAM...99a8dbd3dbf211

vkrastev November 10, 2011 08:40

Quote:

Originally Posted by praveen (Post 331483)
Though there was a redundancy, I dont think phi was the problem. Time step does not seem to have been properly set for restarted cases. The below fix is also required for the same bug that vkrastev reported

https://github.com/OpenFOAM/OpenFOAM...99a8dbd3dbf211

No, the problem was actually phi: the time step initialization fixing does not have any effect on the restarting problem

V.

vkrastev November 10, 2011 08:41

Quote:

Originally Posted by laurensvd (Post 331482)
A beginners question (but googling for commit doesnt seem to work :D), how do you 'commit' such an update? Is it related to svn (my it-administrator doesnt allow this)? If its just the rhoCentralFoam.C or rhoCentralFoam.H that is changed, could someone post this change so I can manually fix it if commit is no option? If the only change is the deletion of this one line of code for phi and adding the other as mentioned above, forget I asked something ;)

Search for github OpenFOAM 2.0.x and see the latest commits

V.

praveen November 10, 2011 09:52

Quote:

Originally Posted by vkrastev (Post 331542)
No, the problem was actually phi: the time step initialization fixing does not have any effect on the restarting problem

V.

OK. Is phi used for some other purpose ? Why aren't the other fluxes phiUp and phiEp similarly declared in createFields.H ? Would like to understand this since I have modified rhoCentralFoam for my own needs.


All times are GMT -4. The time now is 11:31.