rotating fluids
 

Hello FOAMers,

i'm playing around with simulations of rotating fluids. For steady-state simulations i choose MRFSimpleFoam to do the job, but unfortunately i only get the coriolis and centripetal forces added to the patches and not to the inner fluid. That must be possible at all!?
I wrote the inner cells to cellZones, which are identified by the constant/MRFZones. MRFSimpleFoam runs, but coriolis and centripetal forces operate only on the cells next to the boundary (sphere). I don't understand this behaviour?
May someone help me out...

Thanks,
Stefan

BTW: I am using 2.0.x and 1.6-ext!

hello Stefan and foamers,

I am beginner in MRFSimpleFoam, and i have some problems

1. Is it possible to use MRFSimpleFoam solver after using stitchMesh between two 'interface's (since i have to import mesh from star ccm+) in official OpenFOAM version (like OF 1.7.1 or OF 2.0.0 )? or I have to look for any .ext version, so that i can use 'ggi' boundary.

2. while performing stitchMesh in OF 1.7.1, i am able to apply stitchMesh suucessfully, but in 'boundary' file (which is created in new time directory) for some stitched patches it is showing some nfaces. So, i used stitchMesh again on that surfaces, then it shows there are no faces on that patch. and after running simulation it runs but it will not able to open in paraFoam (error is - number of cell/faces/points are non-matching with field) why is it so?

here checkMesh showing no error at all.

3. what kind of boundary condition should i apply on that interfaces for p, u etc.

Thanks in advance

Regards
Suhas

Hi Suh,

as far as i know, GGI is exclusively implemented in 1.6-ext (1.5-dev as well)!
It is not clear to me, why you want to use MRFSimpleFoam with GGI. Its a steady-state solver where you can perform simulations of uniform rotating parts (in a non-inertial system -> adding coriolis and centripedal forces as momentum source). GGI is a topological change of your mesh (sliding interface), which is provided by dynamicFvMesh class and can be used only with transient solvers, i think. Please correct me, if i'm wrong!

For GGI you need the sliding interface, where you access your GGI parameters.
For stitching two meshes together at this sliding interface, i suggest the following procedure:
(1)
Create your separate meshes and name the boundaries (which become the sliding interface) differently, like masterGgiPatch and slaveGgiPacth.
(2)
Merge these two meshes and you will have both (masterGgiPatch and slaveGgiPacth) in your boundary file.
(3)
Now stitch the mesh together. The masterGgiPatch will hold all the faces (nFaces=all faces of sliding interface) and the slaveGgiPacth still exist with zero Faces (nFaces=0), i guess.
(4)
Simply delete the slaveGgiPacth and correct the number of elements accordingly in the boundary file.
(5)
Check your mesh.


Hope that helps,
but back to my problem. I think my case set-up causes the described behavior, the solvers should absolutely works on selected interior cells.

/Stefan

There may be situations where you have a non-conformal grid interface in a model without the requirement to run sliding mesh or transient calculation at all. Therefore, it is possible to use a ggi to simply connect the two mesh parts. This is available in 1.6-ext and 1.5-dev only. However, it is EXTREMELY slow for large models and scales poor in parallel. If you have a large model avoid using ggis.
Stitchmesh did not really work for me on arbitrary non-conformal patches. I my eyes f you have proSTAR4 import the ccm-file into this and run cptransform there. Cptransform is the best algorithm I am aware of to "stitch" non-confromal meshes. Afterwards you can export a confromal mesh.

Regards Bastian

hello foamers,

I am able to stitch hexahedra and polyhedra mesh in 0F 1.7.1 adjusting some tolerances from toleranceDict file.

but still I not ran my simulation, once I do that I will let you know if it works fine or not.:)

Thank you.

Sounds good. Can you provide some details about used tolerances (toleranceDict-File) and some pictures of the face zones you where stitching? Thanks.

Regards Bastian

I use stitchMesh routinely to combine regions from starccm+ meshes with multiple interfaces. You should not have to run it more than once for the same interface (region pair). The face patches for each side must have the same number of faces and be completely conformal or it will not work. If you do any manual repairing of the surface mesh in ccm+ this may not be the case as I have found it sometimes can screw up its own interfaces. Of course, in the case where you have one side of the interface that is a subset of the opposite patch (with the actual interfacing part being perfectly conformal) then this works fine and the remaining faces will stay in its own patch after stitching. One annoying thing is that you have to go into polyMesh/boundary and delete the patches with 0 faces after the stitching. BTW, I also find it necessary to cp to somewhere the cellZones file before stitching and then stick it back in after the stitching to retain your correct regions definitions for the MRF. Hope this helps.

Guess someone ought to respond to your original post before suh hijacked it...

I have no experience with steady-state simulations for this and without more details about your specific problem it is difficult to give a good answer to your problem. How is it you are determining the rotating forces are only being applied to the patches? I assume you have configured your constant/MRFZones file correctly with the right rotating cellZone name and any non-rotating patches in that zone? When you run the simulation, if you start everything from rest (0 velocity) at first it will indeed look like the walls are moving and the inner fluid is not--remember this is a relative frame of reference--so at time 0 the walls are indeed moving relative to the fluid (assuming the fluid starts at rest) since the BCs on the walls are instantaneous imposed. Perhaps it is working correct and you are just not understanding what you are seeing. The velocity in 0/U is the absolute velocity so it is not starting up as though everything is already uniformly rotating which is perhaps what you are thinking. If that isn't the case, more details of your setup and issues would be helpful to anyone wishing to lend a hand. Good luck!

hi foamers,
sorry for hijaking thing from Stefan post...
Though I got good help from Stefan,Bastil and you.

Used command is
stitchMesh <masterPatch> <slavePatch> [-toleranceDict] [Name of file]

About toleranceDict
Previously it has

pointMergeTol 0.05;
edgeMergeTol 0.01;
nFacesPerSlaveEdge 5;
edgeFaceEscapeLimit 10;
integralAdjTol 0.05;
edgeMasterCatchFraction 0.4;
edgeCoPlanarTol 0.8;
edgeEndCutoffTol 0.0001;

I changed it to-

pointMergeTol 0.3;:confused:
edgeMergeTol 0.0201;:confused:
nFacesPerSlaveEdge 5;
edgeFaceEscapeLimit 10;
integralAdjTol 0.8;:confused:
edgeMasterCatchFraction 0.4;
edgeCoPlanarTol 0.8;
edgeEndCutoffTol 0.0001;

I attached these interfaces images as below. There are no faces left on that interfaces after stitching. so after stitching i can not able to show you that interfaces.
If i I am wrong in adjusting tolerances then plz correct me.

Now I have one doubt that MRF methodology will work here or not? or it requires some additional inputs?

Thank you
Regards
Suhas

Suhas,

Adjusting the tolerance dict so that all faces matching perfectly seems to be the right way! Does MRF work properly?

I still have problems with setting up a simple case where i want to rotate a fluid within a circular cylinder. See the attached figures... The coriolis forces are added to the boundary patches, but not to the interior fluid domain!? The mesh is created with blockMesh and the cellZones file are created automatically due to named cellZones within blockMeshDict. I am confused though the only difference to the mixerVessel2D tutorial is that in my case all cells are within the MRFZone! I don't get it.


May someone could bring some light in the dark? Thanks for that!

Stefan

Hi Stefan,

Yes, the MRF works fine after using stitchMesh.

I used it on mesh which comes from star ccm+, and I really don't have any knowledge with blockMesh. So sorry for that.

I am able to use MRFSimpleFoam, and got results but I have results for compressible simulation, so I am now playing with rhoPorousMRFSimpleFoam. So, I don't know about my results from MRFSimpleFoam are correct are not. But, I seen the variation of any variable across the cell zone and not as in your case. If I came across any answer I will let you know.

Regards
Suhas

Hi,

to be honest, I haven't used MRFSimpleFoam at all, so please don't expect too much from the following ;). Have you tried to figure out where the coriolis force is actually set in the code itself? I have had a brief look into
and from what I've seen in there, I guess that solely the boundaryField is updated and the internalField is not taken into account.

I hope this helps,
Jens

I am not quite sure, if only boundary patches are fetched by MRFSimpleFoam. Confusingly enough, now it works when i switching turbulence on! See attached figures once again... For my first trials, i did laminar simulations!

Hence, light in the dark is still appreciated!

Stefan

Kwardle,

After I stitchMesh a mesh generated by STAR-CCM+ (an rotating impeller in a tank), it gives me two cell zones, i.e, cellZone_1 and cellZone_2 in /constant/polyMesh/sets (I used -overwrite option). I am not sure which cell zone I should choose to be the rotating zone? Anyway, I created an MRFZones file and chose cellZone_1 judging by the number of cells and corrected the rotation axis (default in STAR-CCM+ is y).
I put this file at /constant and then initialized epsilon,, k, p, U and nut in /0 file. I also cleared the interface patches (with 0 faces) from all the boundary lists.

I got the following error message:

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Reading field p

Reading field U

Reading/calculating face flux field phi

Selecting incompressible transport model Newtonian
Selecting RAS turbulence model kEpsilon
kEpsilonCoeffs
{
Cmu 0.09;
C1 1.44;
C2 1.92;
sigmaEps 1.3;
}


SIMPLE: no convergence criteria found. Calculations will run for 500 steps.


Starting time loop

Time = 1

smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 0.00801664, No Iterations 2
smoothSolver: Solving for Uy, Initial residual = 1, Final residual = 0.00774384, No Iterations 2
smoothSolver: Solving for Uz, Initial residual = 1, Final residual = 0.00802218, No Iterations 2
GAMG: Solving for p, Initial residual = 1, Final residual = 0.0301432, No Iterations 4
time step continuity errors : sum local = 0.0745659, global = 0.0231848, cumulative = 0.0231848
#0 Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigFpe::sigHandler(int) in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 in "/lib/libc.so.6"
#3 Foam::LimitedScheme<double, Foam::limitedLinearLimiter<Foam::NVDTVD>, Foam::limitFuncs::magSqr>::limiter(Foam::Geometric Field<double, Foam::fvPatchField, Foam::volMesh> const&) const in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#4 Foam::limitedSurfaceInterpolationScheme<double>::w eights(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) const in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#5 Foam::fv::gaussConvectionScheme<double>::fvmDiv(Fo am::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) const in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#6 Foam::tmp<Foam::fvMatrix<double> > Foam::fvm::div<double>(Foam::GeometricField<double , Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::word const&) in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libincompressibleRASModels.so"
#7 Foam::tmp<Foam::fvMatrix<double> > Foam::fvm::div<double>(Foam::GeometricField<double , Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libincompressibleRASModels.so"
#8 Foam::incompressible::RASModels::kEpsilon::correct () in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libincompressibleRASModels.so"
#9
in "/opt/openfoam201/platforms/linux64GccDPOpt/bin/MRFSimpleFoam"
#10 __libc_start_main in "/lib/libc.so.6"
#11
in "/opt/openfoam201/platforms/linux64GccDPOpt/bin/MRFSimpleFoam"
Floating point exception

Do you have any idea where it goes wrong?

Thanks,

Fiona

Hi,

You can able to see the cellZone separately in paraFoam by using VTK file format. The command is

foamToVTK -cellSet cellZone_1 like this example.

for other errors give details of your system directory files.

Regards
Suhas

Fiona,
The cellZones will match the regions in your ccm+ mesh and be in the same order. So cellZone_1 should be the first region, etc. You could also just check the number of cells in each one and match these with your ccm+ regions (as it sounds like you did). As for your error, it looks to be related to kEpsilon. Have you tried running the same case as laminar to make sure everything is working before turning on turbulence? You may want to double-check your BCs on k and epsilon. My guess is that there is some inconsistency somewhere.
Hope this is useful,
Kent

Suhas and Kent,

Thank you both for your reply.

Here is the list of directory/files:
/0
/cellId
/cellType
/epsilon
/k
/meshPhi
/nut
/p
/U
/constant
/MRFZones
/polyMesh
/boundary
/cellZones
/faces
/faceZones
/meshModifiers
/neighbour
/owner
/points
/pointZones
/sets
/cellZone_1
/cellZone_2
/RASProperties
/transportProperties
/system
/controlDict
/fvSchemes
/fvSolution

after running "foamToVTK -cellSet cellZone_1", I've got a directory "VTK" in case root directory and then I am able to choose "Use VTKPolyhedron" & "Include Zones" and see "cellZone_1" and "cellZone_2".

However I also got an error message as follow:
#0 Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigSegv::sigHandler(int) in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 in "/lib/libc.so.6"
#3
in "/opt/openfoam201/platforms/linux64GccDPOpt/bin/foamToVTK"
#4
in "/opt/openfoam201/platforms/linux64GccDPOpt/bin/foamToVTK"
#5
in "/opt/openfoam201/platforms/linux64GccDPOpt/bin/foamToVTK"
#6 __libc_start_main in "/lib/libc.so.6"
#7
in "/opt/openfoam201/platforms/linux64GccDPOpt/bin/foamToVTK"
Segmentation fault

Kent is right. After I turn off turbulence in /constant/RASProperties, I was able to run but results are wrong. I have a velocity inlet BC at gasInlet and a pressure outlet BC at tank top, two of which have patch boundary type. I guess I failed to specify the correct boundary conditions for these two boundaries with regard to k, epsilon and nut.

Best regards,

Fiona