View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000332 | OpenFOAM | Bug | public | 2011-11-02 22:27 | 2011-11-08 17:55 |
Reporter | vkrastev | Assigned To | henry | ||
Priority | high | Severity | major | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Platform | Linux | OS | Ubuntu | OS Version | 10.10 |
Summary | 0000332: Strange behavior of rhoCentralFoam solver when restarting a simulation at some point | ||||
Description | 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. 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 Reproduce | The 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. | ||||
Tags | No tags attached. | ||||
|
|
|
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. |
|
Ok, I will test it and report back as soon as I can |
|
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) |
|
|
|
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? |
|
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) |
|
restart (3,626 bytes)
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time Create mesh for time = 0.008 Reading thermophysical properties Selecting thermodynamics package ePsiThermo<pureMixture<constTransport<specieThermo<eConstThermo<perfectGas>>>>> Reading field U Creating turbulence model Selecting turbulence model type RASModel Selecting RAS turbulence model SpalartAllmaras SpalartAllmarasCoeffs { sigmaNut 0.66666; kappa 0.41; Prt 1; Cb1 0.1355; Cb2 0.622; Cw2 0.3; Cw3 2; Cv1 7.1; Cv2 5; } Reading thermophysicalProperties fluxScheme: Tadmor Starting time loop Mean and max Courant Numbers = 0.0116665509 0.4794822217 deltaT = 5.06636944e-08 Time = 0.0080000507 diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 diagonal: Solving for rhoUx, Initial residual = 0, Final residual = 0, No Iterations 0 diagonal: Solving for rhoUy, Initial residual = 0, Final residual = 0, No Iterations 0 smoothSolver: Solving for Ux, Initial residual = 3.750210016e-06, Final residual = 1.614790165e-11, No Iterations 4 smoothSolver: Solving for Uy, Initial residual = 2.251666888e-05, Final residual = 1.254103204e-12, No Iterations 6 diagonal: Solving for rhoE, Initial residual = 0, Final residual = 0, No Iterations 0 smoothSolver: Solving for e, Initial residual = 1.919391474e-06, Final residual = 6.572060701e-12, No Iterations 4 smoothSolver: Solving for nuTilda, Initial residual = 1.711501306e-05, Final residual = 1.632811743e-12, No Iterations 6 ExecutionTime = 0.27 s ClockTime = 1 s Mean and max Courant Numbers = 0.01216528503 0.4897796449 deltaT = 5.171711351e-08 Time = 0.0080001024 diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 diagonal: Solving for rhoUx, Initial residual = 0, Final residual = 0, No Iterations 0 diagonal: Solving for rhoUy, Initial residual = 0, Final residual = 0, No Iterations 0 smoothSolver: Solving for Ux, Initial residual = 3.825730737e-06, Final residual = 1.750776668e-11, No Iterations 4 smoothSolver: Solving for Uy, Initial residual = 2.296748584e-05, Final residual = 1.396263204e-12, No Iterations 6 diagonal: Solving for rhoE, Initial residual = 0, Final residual = 0, No Iterations 0 smoothSolver: Solving for e, Initial residual = 1.957642157e-06, Final residual = 7.120802639e-12, No Iterations 4 smoothSolver: Solving for nuTilda, Initial residual = 1.731406049e-05, Final residual = 1.836024872e-12, No Iterations 6 ExecutionTime = 0.43 s ClockTime = 1 s Mean and max Courant Numbers = 0.01241824786 0.5115560873 deltaT = 5.054576534e-08 Time = 0.0080001529 diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 diagonal: Solving for rhoUx, Initial residual = 0, Final residual = 0, No Iterations 0 diagonal: Solving for rhoUy, Initial residual = 0, Final residual = 0, No Iterations 0 smoothSolver: Solving for Ux, Initial residual = 3.73340873e-06, Final residual = 1.548896449e-11, No Iterations 4 smoothSolver: Solving for Uy, Initial residual = 2.240229571e-05, Final residual = 1.17744566e-12, No Iterations 6 diagonal: Solving for rhoE, Initial residual = 0, Final residual = 0, No Iterations 0 smoothSolver: Solving for e, Initial residual = 1.908762884e-06, Final residual = 6.293642794e-12, No Iterations 4 smoothSolver: Solving for nuTilda, Initial residual = 1.681234368e-05, Final residual = 1.561274453e-12, No Iterations 6 ExecutionTime = 0.59 s ClockTime = 1 s |
|
no_restart (3,076 bytes)
Mean and max Courant Numbers = 0.0116665431063994 0.46937095453393 deltaT = 4.85866084726227e-08 Time = 0.008 diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 diagonal: Solving for rhoUx, Initial residual = 0, Final residual = 0, No Iterations 0 diagonal: Solving for rhoUy, Initial residual = 0, Final residual = 0, No Iterations 0 smoothSolver: Solving for Ux, Initial residual = 3.59506041072506e-06, Final residual = 1.32648247420957e-11, No Iterations 4 smoothSolver: Solving for Uy, Initial residual = 2.15719408775685e-05, Final residual = 9.58393312965961e-13, No Iterations 6 diagonal: Solving for rhoE, Initial residual = 0, Final residual = 0, No Iterations 0 smoothSolver: Solving for e, Initial residual = 1.83747338122507e-06, Final residual = 5.3955008222507e-12, No Iterations 4 smoothSolver: Solving for nuTilda, Initial residual = 5.99354006957163e-06, Final residual = 1.34288728666557e-12, No Iterations 4 ExecutionTime = 14757.47 s ClockTime = 14774 s Mean and max Courant Numbers = 0.0116665509017334 0.479482221729818 deltaT = 5.06636943965954e-08 Time = 0.00800005066 diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 diagonal: Solving for rhoUx, Initial residual = 0, Final residual = 0, No Iterations 0 diagonal: Solving for rhoUy, Initial residual = 0, Final residual = 0, No Iterations 0 smoothSolver: Solving for Ux, Initial residual = 3.75021001608965e-06, Final residual = 1.61479016895789e-11, No Iterations 4 smoothSolver: Solving for Uy, Initial residual = 2.25166677336211e-05, Final residual = 1.25410360037952e-12, No Iterations 6 diagonal: Solving for rhoE, Initial residual = 0, Final residual = 0, No Iterations 0 smoothSolver: Solving for e, Initial residual = 1.91939147350145e-06, Final residual = 6.57205940965516e-12, No Iterations 4 smoothSolver: Solving for nuTilda, Initial residual = 6.25122489696877e-06, Final residual = 1.56428036027479e-12, No Iterations 4 ExecutionTime = 14757.74 s ClockTime = 14774 s Mean and max Courant Numbers = 0.0121652850286103 0.4897796448567 deltaT = 5.17171135104587e-08 Time = 0.00800010238 diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 diagonal: Solving for rhoUx, Initial residual = 0, Final residual = 0, No Iterations 0 diagonal: Solving for rhoUy, Initial residual = 0, Final residual = 0, No Iterations 0 smoothSolver: Solving for Ux, Initial residual = 3.83014581439549e-06, Final residual = 1.77866606190746e-11, No Iterations 4 smoothSolver: Solving for Uy, Initial residual = 2.29999625765836e-05, Final residual = 1.4307470880081e-12, No Iterations 6 diagonal: Solving for rhoE, Initial residual = 0, Final residual = 0, No Iterations 0 smoothSolver: Solving for e, Initial residual = 1.96046340934368e-06, Final residual = 7.24063691716022e-12, No Iterations 4 smoothSolver: Solving for nuTilda, Initial residual = 6.38166789162216e-06, Final residual = 1.70945191413511e-12, No Iterations 4 ExecutionTime = 14757.89 s ClockTime = 14775 s |
|
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 |
|
|
|
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. |
|
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. Regards |
|
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. |
|
|
|
Thanks. The problem should be resolved by commit dc17e722ab2a9539775eec59650e6dc0e7eb9360 in OpenFOAM-2.0.x, could you pull it and test your case again? |
|
Ok, I'll try the fix and report back |
|
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) Regards |
|
|
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 |