View Issue Details

IDProjectCategoryView StatusLast Update
0002317OpenFOAMBugpublic2016-11-05 20:56
Reporterbjnieuwboer Assigned Tohenry  
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version14.04
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()
     )
 {}
 
relativeVelocityModel.patch (822 bytes)   

wyldckat

2016-11-05 17:15

updater  

relativeVelocityModel.C (4,026 bytes)   
/*---------------------------------------------------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     |
    \\  /    A nd           | Copyright (C) 2014-2016 OpenFOAM Foundation
     \\/     M anipulation  |
-------------------------------------------------------------------------------
License
    This file is part of OpenFOAM.

    OpenFOAM is free software: you can redistribute it and/or modify it
    under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    OpenFOAM is distributed in the hope that it will be useful, but WITHOUT
    ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
    FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
    for more details.

    You should have received a copy of the GNU General Public License
    along with OpenFOAM.  If not, see <http://www.gnu.org/licenses/>.

\*---------------------------------------------------------------------------*/

#include "relativeVelocityModel.H"

// * * * * * * * * * * * * * * Static Data Members * * * * * * * * * * * * * //

namespace Foam
{
    defineTypeNameAndDebug(relativeVelocityModel, 0);
    defineRunTimeSelectionTable(relativeVelocityModel, dictionary);
}


// * * * * * * * * * * * * * * * * Constructors  * * * * * * * * * * * * * * //

Foam::relativeVelocityModel::relativeVelocityModel
(
    const dictionary& dict,
    const incompressibleTwoPhaseInteractingMixture& mixture
)
:
    mixture_(mixture),
    alphac_(mixture.alpha2()),
    alphad_(mixture.alpha1()),
    rhoc_(mixture.rhoc()),
    rhod_(mixture.rhod()),

    Udm_
    (
        IOobject
        (
            "Udm",
            alphac_.time().timeName(),
            alphac_.mesh(),
            IOobject::NO_READ,
            IOobject::AUTO_WRITE
        ),
        alphac_.mesh(),
        dimensionedVector("Udm", dimVelocity, Zero),
        mixture.U().boundaryField().types()
    )
{}


// * * * * * * * * * * * * * * * * Selectors * * * * * * * * * * * * * * * * //

Foam::autoPtr<Foam::relativeVelocityModel> Foam::relativeVelocityModel::New
(
    const dictionary& dict,
    const incompressibleTwoPhaseInteractingMixture& mixture
)
{
    word modelType(dict.lookup(typeName));

    Info<< "Selecting relative velocity model " << modelType << endl;

    dictionaryConstructorTable::iterator cstrIter =
        dictionaryConstructorTablePtr_->find(modelType);

    if (cstrIter == dictionaryConstructorTablePtr_->end())
    {
        FatalErrorInFunction
            << "Unknown time scale model type " << modelType
            << ", constructor not in hash table" << nl << nl
            << "    Valid time scale model types are:" << nl
            << dictionaryConstructorTablePtr_->sortedToc()
            << abort(FatalError);
    }

    return
        autoPtr<relativeVelocityModel>
        (
            cstrIter()
            (
                dict.subDict(modelType + "Coeffs"),
                mixture
            )
        );
}


// * * * * * * * * * * * * * * * * Destructor  * * * * * * * * * * * * * * * //

Foam::relativeVelocityModel::~relativeVelocityModel()
{}


// * * * * * * * * * * * * * * Member Functions  * * * * * * * * * * * * * * //

tmp<volScalarField> Foam::relativeVelocityModel::rho() const
{
    return alphac_*rhoc_ + alphad_*rhod_;
}


tmp<volSymmTensorField> Foam::relativeVelocityModel::tauDm() const
{
    volScalarField betac(alphac_*rhoc_);
    volScalarField betad(alphad_*rhod_);

    // Calculate the relative velocity of the continuous phase w.r.t the mean
    volVectorField Ucm(betad*Udm_/betac);

    return tmp<volSymmTensorField>
    (
        new volSymmTensorField
        (
            "tauDm",
            betad*sqr(Udm_) + betac*sqr(Ucm)
        )
    );
}


// ************************************************************************* //
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