|
|
cavBullet_OF-16x.png (31,242 bytes) |
|
|
cavBubble_OF-22x.png (20,689 bytes) |
|
|
The problem is that incompressibleTwoPhaseMixture::mu() doesn't use the correct alpha1 values. You can see it if you write out mu before and after the execution of alphaEqnSubCycle.H in the solver: ///////////////////////////////////////////////// volScalarField mu ( IOobject ( "mu", runTime.timeName(), mesh, IOobject::NO_READ, IOobject::NO_WRITE ), twoPhaseProperties->mu() ); mu.write(); # include "alphaEqnSubCycle.H" volScalarField mu2 ( IOobject ( "mu2", runTime.timeName(), mesh, IOobject::NO_READ, IOobject::NO_WRITE ), twoPhaseProperties->mu() ); mu2.write(); ///////////////////////////////////////////////// In version 1.6 you get new alpha1 and mu values after alphaEqnSubCycle.H. In version 2.2.x you get the same alpha1 values as in version 1.6 (if you use nonOrthoDeltaCoeffs in MULES::implicitSolve and fvPatch::deltaCoeffs) but mu does not change and it has the same values as before alphaEqnSubCycle.H. |
|
|
Interim solution until the bug is fixed: Info<< "Time = " << runTime.timeName() << nl << endl; #include "alphaEqnSubCycle.H" twoPhaseProperties().alpha1() = alpha1; if (pimple.nCorrPIMPLE() == 1) // is that correct?? { interface.correct(); } |
|
|
The solution would be to remove, Info<< "Reading field alpha1\n" << endl; volScalarField alpha1 ( IOobject ( "alpha1", runTime.timeName(), mesh, IOobject::MUST_READ, IOobject::AUTO_WRITE ), mesh ); and add the following for alpha1, Info<< "Creating phaseChangeTwoPhaseMixture\n" << endl; autoPtr<phaseChangeTwoPhaseMixture> twoPhaseProperties = phaseChangeTwoPhaseMixture::New(U, phi); volScalarField& alpha1 = const_cast<volScalarField&>(twoPhaseProperties->alpha1()); const dimensionedScalar& rho1 = twoPhaseProperties->rho1(); const dimensionedScalar& rho2 = twoPhaseProperties->rho2(); const dimensionedScalar& pSat = twoPhaseProperties->pSat(); Kind Regards, Andreas FEYMARK |
|
|
Thanks for the bug-report and analysis. Sorry that resolving this had to be delayed until after our UGM. I have updated interPhaseChangeFoam to be more consistent with interFoam which also resolves the issue reported here. commit 27abff1c208e00ffaf62a06f3b231425dd4b2bd8 |
|
|
What about the the 'if' condition of the interface correction? Maybe it doesn't belong into this bug report but a further point is the usage of the deltaCoeffs in MULES::implicitSolve and fvPatch::deltaCoeffs. I think the nonOrthDeltaCoeffs would correspond to the implementation in older OpenFOAM versions. Do we really use the right deltaCoeffs everywhere? |
|
|
> What about the the 'if' condition of the interface correction? Well, it is not clear if the interface properties (surface tension) should be used or not as it not necessarily known if the interface is captured (sheet/continuous cavitation) or bubbly. In the case of continuous resolved cavitation interface compression could/should be used but in the case of bubbly cavitation an Euler-Euler approach should be used with appropriate models for the size distribution, drag, etc. However thu current logic is not sensible and I will change it to be consistent with the current interFoam. The deltaCoeffs in MULES::implicitSolve are only used to estimate an appropriate face Courant number for the limiter and the current coding is more appropriate than using nonOrthDeltaCoeffs. I am not sure which fvPatch::deltaCoeffs usage you are referring to, could you clarify? |
|
|
const Foam::scalarField& Foam::fvPatch::deltaCoeffs() const { return boundaryMesh().mesh().deltaCoeffs().boundaryField()[index()]; } |
|
|
What is your issue with this code with respect to interPhaseChangeFoam or in general? |
|
|
Just in general. I'm wondering if there is a special reason why it's done in a different way than in older versions and if it can have a negative influence in certain situations. So far, I didn't observe any significant difference but I didn't test with bad meshes. |
|
|
The new structure makes a formal distinction between the "real" deltaCoeffs and those used for non-orthogonal corrected schemes for many reasons in particular code transparency and to make it possible to support alternative non-orthogonal corrected snGrad schemes. |
- Anonymous
