View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002317 | OpenFOAM | Bug | public | 2016-11-03 11:06 | 2016-11-05 20:56 |
Reporter | bjnieuwboer | Assigned To | henry | ||
Priority | high | Severity | major | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Platform | GNU/Linux | OS | Ubuntu | OS Version | 14.04 |
Summary | 0002317: DriftFluxFoam tutorial 'dahl' does not settle | ||||
Description | When 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 Reproduce | Run the dahl tutorial | ||||
Tags | No tags attached. | ||||
|
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. |
|
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.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) ) ); } // ************************************************************************* // |
|
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. |
|
@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. |
|
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. |
|
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? |
|
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. |
|
Resolved in OpenFOAM-4.x commit 8e01ae0462c90f06af7fba33dca9fef5cb63f26e Resolved in OpenFOAM-dev commit 54c516120ca96dec8dc671a92768c3bbfab678d3 |
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 |