View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002337 | OpenFOAM | Bug | public | 2016-11-17 14:10 | 2016-12-09 04:03 |
| Reporter | buelowp | Assigned To | wyldckat | ||
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | GNU/Linux | OS | Ubuntu | OS Version | 14.04 |
| Summary | 0002337: pimpleFoam, rhoPimpleFoam unstable at small Courant numbers (time-steps) | ||||
| Description | I am encountering a peculiar problem in a number of my simulations with pimpleFoam and rhoPimpleFoam. When I run my cases at reasonably large Courant numbers (maxCo from 50 to 10000, say) they are nicely stable, but I don't have the time-accuracy I would like. So I lower the maxCo down to something on the order of 1 or smaller (e.g. 0.3) to improve my time-accuracy, however, my solution then goes unstable. This is the exact opposite behavior from what I would expect: stable at small maxCo and unstable at large maxCo. Attached is an example pimpleFoam case that demonstrates the behavior. If you set the maxCo to a large value (say 100) then the solution converges just fine. However, if you set the maxCo to a small value (try 1.0, or 0.5 or smaller) the solution goes unstable. It may take a few hundred iterations to see the instability grow, but as the solution continues to run, the instability worsens. I have defined a couple of animation slices (y and z-direction) where you can plot the progression of the instability in the U-field. I'm running OpenFOAM version 3.0.1 (and 4.0) on Ubuntu 14.04 LTS. In the attached case, I used cfMesh to generate the cartesian mesh. CheckMesh indicates that I have a good quality mesh. I have also converted the mesh to Fluent (FoamMeshToFluent) and ran it in Fluent, and it ran fine at Courant Numbers smaller than 1. | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
Fluent has a lot of neat features for ensuring that things work almost on its own, while with OpenFOAM requires that a correct case set-up is used (or at least good one), in order for things to be simulated properly. Looking at the case you've provided, my first major suspicion is the mesh: from my experience, the mesh looks really bad for the kind of simulation you're trying to perform, even if 'checkMesh' gives an OK evaluation. The mesh is not uniform enough, refinement transitions almost feel randomly placed and the layers change too much throughout the mesh. Even though cfMesh is a really great mesher, this mesh doesn't look good due to poor set-up. The first step to fix this would be to align the geometry with the mesh; then to make well planned refinement transitions. As for the simulations with large versus small time steps: large time steps gloss over a lot of details, as you are already aware. Based on how the cell distribution is done in the mesh and using a maximum Courant number of 50 or 100, gives me the feeling that in a single time step, any finite volume of fluid coming in from the inlet, is already leaving through the outlet in the same time step. This means that a lot of flow details are not even acknowledged. When I tested the provided case with something like the following settings in "fvSchemes.PIMPLE": nOuterCorrectors 40; nCorrectors 10; nNonOrthogonalCorrectors 5; the simulation felt a bit more stable, although it's a lot more computationally expensive and pretty much an impractical solution. Therefore, my assessment here is that this case is too much on the side of a "user support request", for which this bug reporting platform was not designed for, as briefly explained in section "Report Issues & Fix Bugs" of the "Development" page: http://openfoam.org/dev/#layers-widget-layers-pro-call-to-action-5 I'm closing this bug report as "no change required". |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-11-17 14:10 | buelowp | New Issue | |
| 2016-11-17 14:10 | buelowp | File Added: Unstable_v301_v40.tgz | |
| 2016-12-09 04:03 | wyldckat | Note Added: 0007441 | |
| 2016-12-09 04:03 | wyldckat | Assigned To | => wyldckat |
| 2016-12-09 04:03 | wyldckat | Status | new => closed |
| 2016-12-09 04:03 | wyldckat | Resolution | open => no change required |
