View Issue Details

IDProjectCategoryView StatusLast Update
0002317OpenFOAM[All Projects] Bugpublic2016-11-05 20:56
ReporterbjnieuwboerAssigned Tohenry 
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Product Version 
Fixed in Version 
Summary0002317: DriftFluxFoam tutorial 'dahl' does not settle
DescriptionWhen running the dahl tutorial using DriftFluxFoam, the alpha field does not settle. I have tested this with OpenFOAM 4.x-90f400ead5e8, OpenFOAM plus-cf6a3662c094 and OpenFOAM 3.0.x-27da24b530cf. The alpha field settles well in OpenFOAM 3.0.x. However, the alpha field does not settle in OpenFOAM 4.x and OpenFOAM plus. The Udm field does show a settling velocity in all the three cases, but that is not imposed on the alpha field for the 4.x and plus case.

When I compared the 3 versions of the code of the solver, I did not see noticeable changes. Therefore I think the bug is located somewhere deeper in the code. Could you figure out what is causing this?
Steps To ReproduceRun the dahl tutorial
TagsNo tags attached.

Activities

wyldckat

2016-11-05 16:12

updater   ~0007097

I was curious and here's a bit more information on this.

When comparing the first saved time snapshot at 50s, as shown in the attached image "dahl_30x_versus_4x.png", it almost looks like the gravity vector changed orientation from Y to X.

But the case is still identically set-up. The commit cf6a3662c094 in OpenFOAM-plus is still mostly the same the code in OpenFOAM-v1606+, which is using the commits from OpenFOAM-dev up to 449a9ec (21-04-2016), which does help isolate a bit better which change in the code altered this behaviour completely.

This also means that the changes made for the "-postProcessing" option hadn't been integrated yet and that the re-work made for the "Robust data handling" feature mentioned in the release notes was already implemented: http://openfoam.org/release/4-0/#software-management-development - I mention these two since they seem the main suspects that popped up in my head.

dahl_30x_versus_4x.png (36,367 bytes)
dahl_30x_versus_4x.png (36,367 bytes)

wyldckat

2016-11-05 17:15

updater   ~0007098

OK, I've found the reason for the big difference in results... problem is that I don't know why the commit was made? The commit in question was this: https://github.com/OpenFOAM/OpenFOAM-dev/commit/626580f5248e2c9ed9c8e372c4076612d00c6baf

Attached are two files, which essentially revert said commit:

  - "relativeVelocityModel.C" - which replaces "applications/solvers/multiphase/driftFluxFoam/relativeVelocityModels/relativeVelocityModel/relativeVelocityModel.C" in both OpenFOAM-4.x and OpenFOAM-dev.

  - "relativeVelocityModel.patch" - which shows the change made to the code that makes it work the same way it used to.


As far as I can figure out, the problem with the change that was introduced in commit 626580f52, is that the Udm field does not respect the no-slip boundary condition on the walls, when using the "calculated" boundary condition. And if it does not respect the no-slip condition, then the walls essentially become slip boundaries, at least along the Y axis... which strangely enough, seems to be enough of a justification for the "alpha.sludge" field to still slip along the X axis?

relativeVelocityModel.patch (822 bytes)
diff --git a/applications/solvers/multiphase/driftFluxFoam/relativeVelocityModels/relativeVelocityModel/relativeVelocityModel.C b/applications/solvers/multiphase/driftFluxFoam/relativeVelocityModels/relativeVelocityModel/relativeVelocityModel.C
index c8e3bb3..ce39cb9 100644
--- a/applications/solvers/multiphase/driftFluxFoam/relativeVelocityModels/relativeVelocityModel/relativeVelocityModel.C
+++ b/applications/solvers/multiphase/driftFluxFoam/relativeVelocityModels/relativeVelocityModel/relativeVelocityModel.C
@@ -59,7 +59,8 @@ Foam::relativeVelocityModel::relativeVelocityModel
             IOobject::AUTO_WRITE
         ),
         alphac_.mesh(),
-        dimensionedVector("Udm", dimVelocity, Zero)
+        dimensionedVector("Udm", dimVelocity, Zero),
+        mixture.U().boundaryField().types()
     )
 {}
 

wyldckat

2016-11-05 17:15

updater  

relativeVelocityModel.C (4,026 bytes)

henry

2016-11-05 17:32

manager   ~0007099

It is not so simple: the boundary conditions of Udm cannot be set to those of U in general, although it is acceptable for the tutorial cases. I made the change to avoid problems when running with complex inlet conditions for U which do not have a direct counterpart for Udm but while the change was sufficient for the case I was working on at the time it is also is not acceptable in general.

I will rework this code shortly.

wyldckat

2016-11-05 18:07

updater   ~0007100

@Henry: Ah, OK, I didn't manage to deduce those details from the commit message :)

---

I was a bit confused as to how the slip was still occurring, but as far as I can figure out, the reason why the sludge slips along the horizontal walls as to do with the divergence of the tensor term on the U equation:

   fvc::div(UdmModel.tauDm())

Although I haven't expanded the full calculation to determine how exactly the Y values got on the X direction... but the tensor alone is already a fairly good enough of a suspect for what I was trying to figure out.

Anyway, I'll move on to another report.

henry

2016-11-05 18:23

manager   ~0007101

I have implemented a general fix in OpenFOAM-dev:

commit 54c516120ca96dec8dc671a92768c3bbfab678d3
Author: Henry Weller <http://cfd.direct>
Date: Sat Nov 5 18:17:24 2016 +0000

    driftFluxFoam: Corrected Udm BCs
    
    Added 'READ_IF_PRESENT' option to support overriding of the default BCs
    for complex problems requiring special treatment of Udm at boundaries.

if all the tests are successful I will push it into OpenFOAM-4.x also.

bjnieuwboer

2016-11-05 19:59

reporter   ~0007103

Thank you both for looking into this.

@wyldckat: I think the settling behaviour in the 4.x case also explains the fact that the 3.0.x solution is not symmetrical. However, I have not yet figured out what is causing this or why the div(tauDm) whould be causing this. It is something I'll investigate.

@henry, thank you for the fix. As I understand, in some cases there should be a boundary condition added for Udm. Can you give an example for which boundary condition on u, a boundary condition for Udm should be added?

henry

2016-11-05 20:48

manager   ~0007104

None of the cases I have run so far require a special boundary condition on Udm but I have added the option in case it is needed in the future.

henry

2016-11-05 20:56

manager   ~0007106

Resolved in OpenFOAM-4.x commit 8e01ae0462c90f06af7fba33dca9fef5cb63f26e

Resolved in OpenFOAM-dev commit 54c516120ca96dec8dc671a92768c3bbfab678d3

Issue History

Date Modified Username Field Change
2016-11-03 11:06 bjnieuwboer New Issue
2016-11-05 16:12 wyldckat File Added: dahl_30x_versus_4x.png
2016-11-05 16:12 wyldckat Note Added: 0007097
2016-11-05 17:15 wyldckat File Added: relativeVelocityModel.patch
2016-11-05 17:15 wyldckat Note Added: 0007098
2016-11-05 17:15 wyldckat File Added: relativeVelocityModel.C
2016-11-05 17:32 henry Note Added: 0007099
2016-11-05 18:07 wyldckat Note Added: 0007100
2016-11-05 18:23 henry Note Added: 0007101
2016-11-05 19:59 bjnieuwboer Note Added: 0007103
2016-11-05 20:48 henry Note Added: 0007104
2016-11-05 20:56 henry Assigned To => henry
2016-11-05 20:56 henry Status new => resolved
2016-11-05 20:56 henry Resolution open => fixed
2016-11-05 20:56 henry Fixed in Version => 4.x
2016-11-05 20:56 henry Note Added: 0007106