[vkrastev]

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... 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]

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]

Originally Posted by deepsterblue

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]

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]

Originally Posted by deepsterblue

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]

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]

Originally Posted by alberto

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]

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]

I would report

[vkrastev]

Originally Posted by alberto

I would report

Reported! (let's see what happens)

[vkrastev]

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]

Thanks for the update!

[vkrastev]

Originally Posted by alberto

Thanks for the update!

You are welcome!

[praveen]

Originally Posted by vkrastev

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]

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]

A beginners question (but googling for commit doesnt seem to work ), 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]

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]

Originally Posted by praveen

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]

Originally Posted by laurensvd

A beginners question (but googling for commit doesnt seem to work ), 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]

Originally Posted by vkrastev

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.