You either - generate your co
- generate your correct cyclics in blockMesh
- generate a correct mesh first and then create the cyclics using createPatch.
The blockMesh you created has some partially defined cyclics it seems so cannot be loaded/morphed. Check the cyclic patch definition in the blockMeshDict.
Sorry, but I don't understand
Sorry, but I don't understand what you mean. What should be wrong in the blockMeshDict patch definition? The blockMesh utility is running correctly and the mesh is ok.
What I want to do is:
I have four surfaces with the same number of cell faces and at each equal cell face it should the same cyclic bc. For the createPatch utility I need to specify the faces with an patch and since version 1.3 multiple patches are allowed. And so I thought I could do four cyclic patches:
When the patch definition is wall, patch etc. it works but not when the patch definition is cyclic.
In this case I have merge two surfaces in one patch, so I need only one patch definition in the createPatchDict and there is only one error and not four but it is the same. And there are no multipli patches.
And because the old patches are removed with the createPatch utility it doesn't matter how the patch is defined in the blockMeshDict. Or am I wrong?
Thanks, a lot.
Servus, has anybody a testc
has anybody a testcase for the createPatch utility with cyclic patches that is running correctly with version 1.3 ?
Take e.g. the cavity and put c
Take e.g. the cavity and put cyclics on frontAndBack.
I think the problem is the multiple cyclics. The automatic matching expects the cyclic halves to be non-connected or separated by a sharp angle.
So do one opposing pair first, then change the type to e.g. polyPatch by editing the boundary file, do the second opposing pair, change their type to polyPatch etc. until all your pairs are matched up.
Then change all those polyPatches back to cyclics.
I have modified the cavity cas
I have modified the cavity case, so that it is a real cube with 5 cells at each edge. When I change the frontAndBack patch definition from empty to patch and the createPatchDict looks like this:
It comes the following warning message very often:
Copying patch movingWall at position 0
Copying patch fixedWalls at position 1
Copying patch frontAndBack at position 2
Adding new patch cyclicFront of type cyclic as patch 3
Moving faces from patch frontAndBack to patch 3
Removing empty patch frontAndBack
movingWall size:25 start:300
fixedWalls size:75 start:325
cyclicFront size:0 start:400
--> FOAM Warning :
From function min(const UList<type>&)
in file /home/dm2/henry/OpenFOAM/OpenFOAM-1.3/src/OpenFOAM/lnInclude/FieldFunctions.C at line 362
empty field, returning zero
--> FOAM Warning :
From function max(const UList<type>&)
in file /home/dm2/henry/OpenFOAM/OpenFOAM-1.3/src/OpenFOAM/lnInclude/FieldFunctions.C at line 341
empty field, returning zero
But when I disable the movingWall and fixedWall patches in the blockMeshDict, then it works.
And when there are more then one patch at
it doens't works with cyclic and the old error message comes again.
Thanks, very much.
Is bug in createPatch. - In
Is bug in createPatch.
- In mesh/manipulation/createPatch/createPatch.C comment out the check for whether the patch has changed on line 338. (so always do the repatcher.changePatchID)
yeah this really fixes the pro
yeah this really fixes the problem http://www.cfd-online.com/OpenFOAM_D...part/happy.gif
btw: why does the util create the new "stuff" in a new directory instead of overwriting it?
Well it work's sometimes. When
Well it work's sometimes. When I combine
patches( surface_1 surface_3)
patches( surface_2 surface_4)
then it is running correctly. But when I combine
patches( surface_1 surface_2)
patches( surface_3 surface_4)
then it comes the first error message. At this time there are no multiple cyclic patches! The surfaces are side by side from one to four.
It is possible to make multiple cyclic patches? With a patch or wall definition it is possible.
Can you send me a simple block
Can you send me a simple blockMeshDict which replicates the problem? Send to m.janssens
Hi Oliver, - your case cann
- your case cannot be handled by createPatches - it has to be done by the mesh generator. This is because the two patches you are trying to merge are connected and in-line. createPatches just bunches the faces to-be-merged together and then tries to split it into two equal sets using some geometric or topological feature.
- I can couple the non-neighbouring front_01 and front_03 if I start off with everything polyPatch.
- you can switch on the 'cyclic' debug switch in the controlDict if you want some more info on what it does 'under the hood'.
some times two patches are cyc
some times two patches are cyclic for velocity field but are not so for scalar field. So on need to select them in different way for specifying b.c. for velocity and scalar field.
I tried to define the patches as:
since in the user guide 6.2.2 it says that
Enables two patches to be treated as if they are physically connected; used for repeated geometries"
In this way I call the b.c of the scalar on patch1 and patch2 while calling the cyclic b.c for velocity on patch12. But I got error that means that cyclic is not expecting a patch name in its list. I then tried to copy the contents of patch1 faces and patch2 face into cyclic patch12, I got an error that I'm using faces that are part of previously defined patch. It seems that a face can only be part of a single patch. I'm using V1.2
Can this problem be solved with createPatch?
The polyPatch has to be cyclic
The polyPatch has to be cyclic since this is about additional topological information (i.e. connectivity across the patch). This is purely a mesh issue.
Then you set up boundary conditions which in your case do something special. Quite possibly your scalar b.c. (fixedValue?) cannot be defined on a cyclicPolyPatch and you'll have to define your own boundary condition. The sources for boundary conditions (for finite volume) are all in $FOAM_SRC/finiteVolume/lnInclude/
so the library does not allow
so the library does not allow a face to be part of two different patches, does it? if so, would not it be easier if I remove such constrain? I wonder if this can have some bad effect on the way OpenFOAM works? If the constrain is removed then the problem is solved by:
apply fixed scalar value b.c. on patch1.
apply Neumann b.c. for the scalar on patch2.
apply cyclic velocity on patch12.
Thanks for you prompt reply.
|All times are GMT -4. The time now is 18:09.|