View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001471OpenFOAMBugpublic2014-12-30 11:502015-05-01 00:48
Reporterwill Assigned Tohenry  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSOpenSuSEOS Version13.1
Summary0001471: MULES explicitSolve bug with sub-cycling on moving meshes
DescriptionMULES::explicitSolve calls fvc::surfaceIntegrate, which in turn divides the calculated field by the cell volumes. The volume at the end of the timestep is used for this division. I think it should be the sub-cycled cell volume.

The change can either be made in MULES::explicitSolve or fvc::surfaceIntegrate. I've attached a git.diff showing both.
Steps To ReproduceThe attached case is a 1D interDyMFoam problem. The case is just stationary air over water. The mesh is moved at the base. Without the fix, the alpha field is unphysically reduced by the motion.
TagsNo tags attached.

Activities

will

2014-12-30 11:50

manager  

column.tar.gz (5,289 bytes)

will

2014-12-30 11:50

manager  

MULESSubCycleBug.diff (999 bytes)    
diff --git a/src/finiteVolume/finiteVolume/fvc/fvcSurfaceIntegrate.C b/src/finiteVolume/finiteVolume/fvc/fvcSurfaceIntegrate.C
index faaf05c..425074d 100644
--- a/src/finiteVolume/finiteVolume/fvc/fvcSurfaceIntegrate.C
+++ b/src/finiteVolume/finiteVolume/fvc/fvcSurfaceIntegrate.C
@@ -72,7 +72,7 @@ void surfaceIntegrate
         }
     }
 
-    ivf /= mesh.V();
+    ivf /= mesh.Vsc();
 }
 
 
diff --git a/src/finiteVolume/fvMatrices/solvers/MULES/MULESTemplates.C b/src/finiteVolume/fvMatrices/solvers/MULES/MULESTemplates.C
index a7a5282..f0ee13c 100644
--- a/src/finiteVolume/fvMatrices/solvers/MULES/MULESTemplates.C
+++ b/src/finiteVolume/fvMatrices/solvers/MULES/MULESTemplates.C
@@ -60,7 +60,7 @@ void Foam::MULES::explicitSolve
             mesh.Vsc0()().field()*rho.oldTime().field()
            *psi0*rDeltaT/mesh.Vsc()().field()
           + Su.field()
-          - psiIf
+          - psiIf*(mesh.V()/mesh.Vsc()().field())
         )/(rho.field()*rDeltaT - Sp.field());
     }
     else
MULESSubCycleBug.diff (999 bytes)   

henry

2014-12-30 12:04

manager   ~0003416

Thanks for the bug-report and fix. Given that fvc::surfaceIntegrate may or may not be used within sub-cycling I am not sure it is a good idea to build into it the use of the sub-cycled volumes; I will think about this more though.

henry

2015-01-02 16:41

manager   ~0003471

I have applied the change to fvc::surfaceIntegrate but sub-cycling in time is only accurate for moving-mesh cases in which the face-areas do not change. So for solid-body motion and simple 1D compression/expansion as in your example but it is not formally applicable for 2 or 3D compression/expansion and other more complex motions.

Resolved by commit 57ad873fd8e58efae633bdd8f39c150f6cc46126

In order to avoid unexpectedly poor results I think it would be better if sub-cycling in time were limited to static meshes and solid-body motion only and the Vsc() function removed and I will consider this for the next release with the addition of a check for solid-body motion in the case that sub-cycling is applied. Now that MULES support semi-implicit operation there is less need for sub-cycling and I would recommend that you use this approach in interDyMFoam for your complex mesh motion cases.

Issue History

Date Modified Username Field Change
2014-12-30 11:50 will New Issue
2014-12-30 11:50 will File Added: column.tar.gz
2014-12-30 11:50 will File Added: MULESSubCycleBug.diff
2014-12-30 12:04 henry Note Added: 0003416
2015-01-02 16:41 henry Note Added: 0003471
2015-01-02 16:41 henry Status new => resolved
2015-01-02 16:41 henry Resolution open => fixed
2015-01-02 16:41 henry Assigned To => henry