|
[Sponsors] |
On "correctFluxes" in dynamicRefineFvMesh solvers |
![]() |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
![]() |
![]() |
#1 |
Senior Member
Kevin van As
Join Date: Sep 2014
Location: TU Delft, The Netherlands
Posts: 252
Rep Power: 20 ![]() |
In dynamic mesh cases (e.g. interDyMFoam), the following entry is inside the "dynamicMeshDict" file for a dynamicRefineFvMesh:
Code:
${FOAM_TUTORIALS}/multiphase/interDyMFoam/ras/damBreakWithObstacle/constant/dynamicMeshDict correctFluxes ( (phi none) (nHatf none) (rhoPhi none) (alphaPhi none) (ghf none) ); However, inside the solver (interDyMFoam), the fluxes seem to be corrected as well, unconditionally: Code:
${FOAM_SOLVERS}/multiphase/interFoam/interDyMFoam/interDyMFoam.C mesh.update(); (...) if (mesh.changing() && correctPhi) { // Calculate absolute flux from the mapped surface velocity phi = mesh.Sf() & Uf; #include "correctPhi.H" // Make the flux relative to the mesh motion fvc::makeRelative(phi, U); mixture.correct(); } Code:
phi = mesh.Sf() & Uf; Question: In other words, am I correct when I say that the values in "correctFluxes" may always be 'none'? Would the same apply to the other fluxes, e.g. alphaPhi? As they also get computed by the solver (as first occurrence): Code:
"solver"/alphaEqn.H tmp<surfaceScalarField> talphaPhiUD(alpha1Eqn.flux()); alphaPhi = talphaPhiUD(); |
|
![]() |
![]() |
![]() |
![]() |
#2 |
New Member
eco
Join Date: Jan 2017
Posts: 5
Rep Power: 9 ![]() |
I come to the same conclusion.
Code:
phi = mesh.Sf() & Uf; The .update() function of dynamicRefineFvMesh executes .refine() and/or .unrefine() which both use the input of correcFluxes from the dynamicMeshDict. For this mesh class the advantage of using the internal flux correction, instead of the line above, seems to be the exclusive treatment of cells that have been modified by the refinement/unrefinement. Those are being marked with the label "-1" and only those fluxes are corrected. See Foam::dynamicRefineFvMesh::refine(const labelList& cellsToRefine): Code:
const labelList& faceMap = map().faceMap(); const labelList& reverseFaceMap = map().reverseFaceMap(); [...] // Recalculate new internal faces. for (label faceI = 0; faceI < nInternalFaces(); faceI++) { label oldFaceI = faceMap[faceI]; if (oldFaceI == -1) { // Inflated/appended phi[faceI] = phiU[faceI]; } else if (reverseFaceMap[oldFaceI] != faceI) { // face-from-masterface phi[faceI] = phiU[faceI]; } } [...] I want to extend the simpleFoam solver by the dynamicRefineFvMesh class. In short, bold is the extension: Code:
#include "fvCFD.H" #include "dynamicFvMesh.H" #include "singlePhaseTransportModel.H" #include "turbulentTransportModel.H" #include "simpleControl.H" #include "fvIOoptionList.H" // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // int main(int argc, char *argv[]) { #include "setRootCase.H" #include "createTime.H" #include "createDynamicFvMesh.H" //#include "createMesh.H" simpleControl simple(mesh); #include "createFields.H" #include "createMRF.H" #include "createFvOptions.H" #include "initContinuityErrs.H" // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Info<< "\nStarting time loop\n" << endl; simpleTime.start(); while (simple.loop()) { Info<< "Time = " << runTime.timeName() << nl << endl; mesh.update(); phi = fvc::interpolate(U) & mesh.Sf(); // --- Pressure-velocity SIMPLE corrector { UEqnTime.start(); #include "UEqn.H" [...] The setting for correctFluxes is in DynamicMeshDict is: Code:
correctFluxes ( (phi none) ); Code:
correctFluxes ( (phi U) ); Code:
[...] Selected 1023 cells for refinement out of 12225. Refined from 12225 to 19386 cells. #0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::sigSegv::sigHandler(int) at ??:? #2 ? in "/lib/x86_64-linux-gnu/libc.so.6" #3 Foam::dynamicRefineFvMesh::refine(Foam::List<long> const&) at ??:? #4 Foam::dynamicRefineFvMesh::update() at ??:? #5 ? at ??:? #6 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #7 ? at ??:? Segmentation fault (core dumped) Code:
// Update master faces forAllConstIter(labelHashSet, masterFaces, iter) { label faceI = iter.key(); if (isInternalFace(faceI)) { phi[faceI] = phiU[faceI]; } else { label patchI = boundaryMesh().whichPatch(faceI); label i = faceI - boundaryMesh()[patchI].start(); //Info<< "Breakpoint" << endl; const fvsPatchScalarField& patchPhiU = phiU.boundaryField()[patchI]; fvsPatchScalarField& patchPhi = bphi[patchI]; patchPhi[i] = patchPhiU[i]; } 1. Where do these jumps in k come from? Is the dynamicRefineFvMesh implementation wrong? 2. Why cant the correctFlux dictionary with the correct velocity field not be used? I am thankful for every hint. |
|
![]() |
![]() |
![]() |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Solid Mechanics Solvers added to OpenFOAM Extend | bigphil | OpenFOAM Announcements from Other Sources | 26 | October 12, 2017 04:01 |
Is there a difference between Riemann solvers and characteristic based solvers? | linkamp | Main CFD Forum | 3 | February 18, 2016 09:12 |
FSI solvers - best solvers | steven123 | OpenFOAM Running, Solving & CFD | 0 | July 8, 2014 10:26 |
Possible turbulence modelling bug in SRF solvers | otm | OpenFOAM Running, Solving & CFD | 3 | May 29, 2012 04:03 |
Reaction solvers | megacrout | OpenFOAM | 5 | July 8, 2011 10:54 |