View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001768 | OpenFOAM | Bug | public | 2015-06-30 02:05 | 2015-10-21 17:25 |
| Reporter | gucong | Assigned To | henry | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | GNU/Linux | OS | Ubuntu | OS Version | 15.04 |
| Summary | 0001768: ddt scheme is not correct when mesh is moving and cut at the same time | ||||
| Description | When trying to implement dynamic mesh with meshing moving and refinement at the same time, I found for example in src/finiteVolume/finiteVolume/ddtSchemes/EulerDdtScheme/EulerDdtScheme.C: fvcDdt: if (mesh().moving()) { ... rDeltaT.value()* ( vf.internalField() - vf.oldTime().internalField()*mesh().Vsc0()/mesh().Vsc() ), } where Vsc0 is the old cell volume and Vsc is the new cell volume. This can make the old field 8 times larger/smaller where the mesh is refined/unrefined. | ||||
| Tags | No tags attached. | ||||
|
|
Sorry. After doing mesh.setV0()=mesh.V(), it is working now. Maybe exposing fvMesh::storeOldVol is better. |
|
|
There should be no need to expose these internals as the automatic mesh-update system should handle them. In this case the old-time volume should be automatically updated follow mesh refinement then the new volumes updated following morphing. It is not clear which solver you are using or how you are organizing the mesh changes. If there is an issue with the automatic mesh-update system it is likely to be fixed already in OpenFOAM-dev. |
|
|
I meant maybe make storeOldVol protected rather than private. Or solve the following problem in some other way. In my dyanmicFvMesh, I first refine/unrefine as in dynamicRefineFvMesh. I found that I have to do this->setV0() = this->V(); before I make the mesh moving by fvMesh::movePoints(motionPtr_->newPoints()); Otherwise, the code will break, for example, fvc::ddt as described in the bug report. This is because fvMesh::updateMesh stores the volume before refinement as V0. And fvMesh::movePionts will not update the V0 if mesh refinement is done previously but in the same time step. |
|
|
Have you tried using OpenFOAM-dev? |
|
|
I will try after I build the dev tree. But I read the related code in dev and found no difference (based on my understanding of the problem). In particular fvMesh::updateMesh stores the volume before refinement as V0. And fvMesh::movePoints doesn't update V0 to the mesh after refinement. This breaks fvc::ddt. fvc::ddt assumes that there is no refinement if mesh is moving. |
|
|
The tutorials/multiphase/interDyMFoam/ras/damBreakWithObstacle case does automatic refinement and unrefinement and work correctly without any change to the code so at least for this case the old-time cell volumes are handled correctly. |
|
|
The tutorial case have no problem. The problem happens when I use refinement and fvMesh::movePoints at the same time step. fvc::ddt assumes that there is no refinement if mesh is moving. |
|
|
If you can setup a case in OpenFOAM-dev which demonstrates the problem and provide it here I will investigate. |
|
|
Orphaned report |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-06-30 02:05 | gucong | New Issue | |
| 2015-06-30 02:28 | gucong | Note Added: 0005017 | |
| 2015-06-30 07:54 | henry | Note Added: 0005018 | |
| 2015-06-30 08:30 | gucong | Note Added: 0005019 | |
| 2015-06-30 08:36 | henry | Note Added: 0005020 | |
| 2015-06-30 08:55 | gucong | Note Added: 0005022 | |
| 2015-06-30 08:55 | gucong | Note Edited: 0005022 | |
| 2015-06-30 08:57 | gucong | Note Edited: 0005022 | |
| 2015-06-30 08:57 | henry | Note Added: 0005023 | |
| 2015-06-30 09:03 | gucong | Note Added: 0005024 | |
| 2015-06-30 09:06 | henry | Note Added: 0005025 | |
| 2015-10-21 17:25 | henry | Note Added: 0005456 | |
| 2015-10-21 17:25 | henry | Status | new => closed |
| 2015-10-21 17:25 | henry | Assigned To | => henry |
| 2015-10-21 17:25 | henry | Resolution | open => no change required |
