View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000332OpenFOAM[All Projects] Bugpublic2011-11-02 22:272011-11-08 17:55
Assigned Tohenry 
PlatformLinuxOSUbuntuOS Version10.10
Product Version 
Target VersionFixed in Version 
Summary0000332: Strange behavior of rhoCentralFoam solver when restarting a simulation at some point
DescriptionI'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. 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! The issue could be related to an insufficient data-write precision, so I've tried to increase a lot the write precision, also passing frotm ASCII to binary format, but nothing helped to solve it. In the attachment there is an example of a torque plot with and without restarting.
Steps To ReproduceThe problem appears when monitoring some field value, either local or integrated, during unsteady runs with rhoCentralFoam with the necessity of a stop-and-restart procedure.
TagsNo tags attached.
Attached Filespng file icon plot_torque.png [^] (4,786 bytes) 2011-11-02 22:27

png file icon plot_torque_new.png [^] (5,555 bytes) 2011-11-04 11:20

? file icon restart [^] (3,626 bytes) 2011-11-04 13:19 [Show Content]
? file icon no_restart [^] (3,076 bytes) 2011-11-04 13:19 [Show Content]
gz file icon testSmall.tar.gz [^] (1,478,123 bytes) 2011-11-06 15:25
gz file icon testSmall201.tar.gz [^] (1,479,074 bytes) 2011-11-07 18:24
png file icon plot_torque_newPhi.png [^] (6,783 bytes) 2011-11-08 17:02

- Relationships

-  Notes
henry (manager)
2011-11-03 16:53

The problem may relate to the failure to initialise deltaT from the previous run during restart of cases with variable time-step. This issue is resolved by
commit 6355c656034dba7648b32c16e899a8dbd3dbf211

Please could you test this change on your case and report back.
vkrastev (reporter)
2011-11-03 17:33

Ok, I will test it and report back as soon as I can
vkrastev (reporter)
2011-11-04 11:20

I've compiled the modified Time.C file and run a new test, but there seems to be no significant changes (see the new plot attached: in red there is the restart with the new Time.C file, in blue the old one)
henry (manager)
2011-11-04 12:33

Could you check if the deltaT is now initialised correctly on restart, i.e is the deltaT for the first two time-steps after restart the same as for the corresponding run without restart?

So far I have not managed to reproduce your problem, could you send a small test-case which reproduces is?
vkrastev (reporter)
2011-11-04 13:18

About the deltaT's, they seem to be initalized correctly (see the files attached called restart and no_restart). About the test case, I'll need some time to build a smaller one (alternatively I can send you the valve case, but I doubt it's small enough for your purposes, as it is an about 90k cells 2D domain)
vkrastev (reporter)
2011-11-06 15:23

Here it is a smaller version of my valve case (the mesh around the valve is exactly the same, but the domain is about 3 times smaller). To check the behavior I am talking about, you can do the following steps:

-first run the case for 0.003 s;
-then restart it from 0.0015 s and again till 0.003 s;
-plot the torque values calculated by the forces function in the two cases and see the difference between them.

Some additional notes:

1) the z axis pressure-related torque output is printed as the 10th column of the forces.dat output file (viscous forces are negligible for this case if compared to the pressure-related ones);

2) I run this case in parallel, on the 4 cores of my intel i7 laptop, and it took me about 1h10 min from 0 to 0.003 s (anyway, I'm quite sure you can shorten a bit the simulation time, e. g. to 0.002 s with the restart at 0.001 s).

Hope this helps to find out where the problem is
henry (manager)
2011-11-07 14:26

I am unable to run your case, it apears that many of the files are out of date. Could you upgrade it to OpenFOAM-2.0.x, see if the restart problem persists and if so post the updated case here for us to investigate.
vkrastev (reporter)
2011-11-07 14:49

Well, I am an OF-1.7.x user (as clearly stated in my initial report), so I would like to know if there is a bug in that version and not only in the latest release (and I think that this matter could be of interest for many users which, as myself, have put a lot of development work in the older releases and don't want to upgrade all of their additional code only to fix a single bug). Anyway, I will try to update the case in a OF-2.0.x-consistent format and resend it as soon as I can.

vkrastev (reporter)
2011-11-07 18:24

Here it is the same test case, but adapted to work with with OF-2.0.x: I've tried it with OF-2.0.1 and the behavior is exactly the same as encountered in OF-1.7.x. To check it, follow the instructions previously posted.
henry (manager)
2011-11-08 12:30

Thanks. The problem should be resolved by
commit dc17e722ab2a9539775eec59650e6dc0e7eb9360
in OpenFOAM-2.0.x, could you pull it and test your case again?
vkrastev (reporter)
2011-11-08 12:43

Ok, I'll try the fix and report back
vkrastev (reporter)
2011-11-08 17:01

I've tried the changes in commit dc17e722ab2a9539775eec59650e6dc0e7eb9360 on OF-2.0.1 and the problem seems fixed: as you can see from the new plot attached, now the no-dump and dumped run return consistent torque values (it is also interesting to underline how the plotted value is significantly different from the old implementation, either with and without restarting, which means that with the old one an error propagated through time and affected the final solution)


- Issue History
Date Modified Username Field Change
2011-11-02 22:27 vkrastev New Issue
2011-11-02 22:27 vkrastev File Added: plot_torque.png
2011-11-03 16:53 henry Note Added: 0000781
2011-11-03 17:33 vkrastev Note Added: 0000784
2011-11-04 11:20 vkrastev Note Added: 0000785
2011-11-04 11:20 vkrastev File Added: plot_torque_new.png
2011-11-04 12:33 henry Note Added: 0000786
2011-11-04 13:18 vkrastev Note Added: 0000787
2011-11-04 13:19 vkrastev File Added: restart
2011-11-04 13:19 vkrastev File Added: no_restart
2011-11-06 15:23 vkrastev Note Added: 0000789
2011-11-06 15:25 vkrastev File Added: testSmall.tar.gz
2011-11-07 14:26 henry Note Added: 0000791
2011-11-07 14:49 vkrastev Note Added: 0000793
2011-11-07 18:24 vkrastev Note Added: 0000794
2011-11-07 18:24 vkrastev File Added: testSmall201.tar.gz
2011-11-08 12:30 henry Note Added: 0000795
2011-11-08 12:43 vkrastev Note Added: 0000796
2011-11-08 17:01 vkrastev Note Added: 0000797
2011-11-08 17:02 vkrastev File Added: plot_torque_newPhi.png
2011-11-08 17:55 henry Status new => resolved
2011-11-08 17:55 henry Resolution open => fixed
2011-11-08 17:55 henry Assigned To => henry