[sampaio]

Hi all,
Quick question:
What is the fastest way to generate a mesh (using blockMesh) with hanging nodes?

I built several block but I wanted to use different number of points in z direction in each one of them.

Would mergePatch do the job? It was not clear from manual if hanging nodes are allowed in merged patches. Looks like not.

Thanks,
Luiz

[hjasak]

You need a paradigm shift - nobody is getting hanged here :-)

As you know, FOAM supports polyhedral cells, i.e. a cell can have as many faces as it likes. In case of hex cells, this looks like what Fluent describes as "hanging nodes"; however, in FOAM you will get proper polyhedral cells.

The easiest way to create some would be to make two hex blocks in blockMesh with different number of cells and merge up the patches using the mergePatchPairs section - try the simpleFoam/pitzDaily3Blockstutorial - copy the block mesh description and mess about with the number of cells in various blocks.

Enjoy,

Hrv

[sampaio]

Thanks Jasak,
But it is complaining my patchs are internal and thus cannot be merged... Which was not the case in tutorial (at least one of the patches to be merged had an external face...).
Is it still possible in my case?
Thanks again,
Luiz

[hjasak]

Try this:

/*---------------------------------------------------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.0 |
| \ / A nd | Web: http://www.openfoam.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/

FoamFile
{
version 2.0;
format ascii;

root "";
case "";
instance "";
local "";

class dictionary;
object blockMeshDict;
}

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //


convertToMeters 0.1;

vertices
(
// Back plane
(0 0 0)
(1 0 0)
(1 0 0)
(2 0 0)
(0 1 0)
(1 1 0)
(1 1 0)
(2 1 0)

// Front plane
(0 0 0.1)
(1 0 0.1)
(1 0 0.1)
(2 0 0.1)
(0 1 0.1)
(1 1 0.1)
(1 1 0.1)
(2 1 0.1)
);

blocks
(
hex (0 1 5 4 8 9 13 12) (2 2 1) simpleGrading (1 1 1)
hex (2 3 7 6 10 11 15 14) (3 3 1) simpleGrading (1 1 1)
);

edges
(
);

patches
(
wall bottom
(
(0 1 9 8)
(2 3 11 10)
)
wall bottom
(
(4 12 13 5)
(6 14 15 7)
)
wall left
(
(0 8 12 4)
)
wall right
(
(3 7 15 11)
)

patch leftMerge
(
(1 5 13 9)
)
patch rightMerge
(
(2 10 14 6)
)
);

mergePatchPairs
(
( leftMerge rightMerge )
);


// ************************************************** *********************** //


Hrv

[sampaio]

Thanks Hrv,
I tried. It worked. But what if I want to merge 4 pairs of patches that share an edge (like in a cross):

-----------------------------
|12.........13||14.........15|
|................||................|
|................||................|
|8.............9||10.........11|
|========||========|
|4.............5||6.............7|
|................||................|
|................||................|
|0.............1||2............3|
-----------------------------

How can I merge faces 1-5 with 2-6, 4-5 with 8-9, etc...?

I tried to merge altogether and separetely, but blockMesh complain about:


Adding point and face zones
Adding topology modifiers


--> FOAM FATAL ERROR : Face 53 reduced to less than 3 points. Topological/cutting error B.
Old face: 2(8 17) new face: 2(53 69)

Function: void slidingInterface::coupleInterface(polyTopoChange& ref) const
in file: slidingInterface/coupleSlidingInterface.C at line: 1667.

FOAM aborting

Aborted


Thanks a lot.
Luiz

[sampaio]

Or else, if there is a block inside my domain (sharing 4 faces with other block in domain)...
How should I merge the pairs? One by one or all together (like the four faces defined in the same patch)? Probably some other option, cause I tried both and it gave the errors posted above.
Thanks,
Luiz

[mattijs]

Hi Luiz,

the merging functionality in blockMesh is also in a separate application called stitchMesh. Put the faces you want to merge into two separate patches and use

stitchMesh <root> <case> <masterpatch> <slavepatch> [-perfect] [-partial]

Without arguments it requires the faces to cover the same area (same behaviour as mergePatchPairs), -perfect is if the faces and points on the patches match exactly, -partial if the slave side faces do not cover all of the master side (or was it the other way around?)

Mattijs

[sampaio]

Hi Mattijs,
But with stitchMesh I can only stitch one pair at a time, right? And when I try to repeat for another patch pair it complains there are coincident points or faces...
Anyway I will double check if I am doing anything wrong... but I wonder if either mergePatch or stitchMesh were originally designed for the purpose I have in mind (merge four adjacent faces sharing a single (geometric) edge, for instance (actually 4 different edges geometrically coincidents)).
Thanks,
Luiz

[mattijs]

Hi Luiz,

You are a bit in uncharted territory here.

If you actually have four topologically different edges and patches there should be no problem. All this coupling (and hence geometric tests) will only be done on a patch by patch basis. Does it work if the edges do not share the same location i.e. you separate the different parts?

[sampaio]

So far I was able to make it work with simple things like Prof. Hrvoje's example.

But when I try to do it with L-shaped patches, where z direction ("wingspan") spacing does not match (non-perfect faces merging), it complains that two adjacent faces share 3 vertices. (In my case, the fact 2 faces share 3 vertices would not be a problem , since these 3 vertices are aligned...). These vertices are located in the corner of the "L". Inside the "L" (on the upper-right) I am setting 16 divisions in z direction, while on the outside, only 8 divisions. If the difference in the number of divisions is in the x or y direction, there is no problem.

If I switch masterpatch with slavepatch, I get a funny message:


...

Default patch type set to empty

Creating merge patch pairs

Adding point and face zones
Adding topology modifiers


--> FOAM FATAL ERROR : Error in point ordering: mixed used and unused points at the end of point list.
Number of used points: 2881 and point 2882 is used by a live face.

Function: void polyMesh::calcFaceCells() const
in file: meshes/polyMesh/calcPolyMeshFaceCells.C at line: 180.

FOAM aborting

Aborted
[luizebs@localhost oodles]$




Am I doing something wrong, or is there any limitation on what I want to do for safety reasons?

Any ideas/suggestion? Should I move to gambit to do this? (does the gambit or fluent converter works well transforming "hanging nodes" in the foam's polyedra?)

I really like blockMesh, so if i could stick with it, I would feel better...

[hjasak]

Actually, having 3 common points is not a problem and the sliding mesh algorithm is designed to work for such cases. The error sounds pretty painless (but should not happen). I can probably give you some more info if you switch some debugging on for me and give me a bigger log file. Try switching on debug for:

polyMesh
polyMeshMorph
primitiveMesh
enrichedPatch
slidingInterface

and see if the log makes more sense.

On the other hand, it may be that you just need some recent bug-fixes. Hmm...

[sampaio]

Thanks Hrvoje,

I can send you the big log file, but let me post where it started to go wrong (I think):

-> FOAM FATAL ERROR : Duplicate point found in cut face. Error in the face cutting algorithm for global face 4(1449 2280 2299 1469) local face 16.
Face: 6(1550 1551 1576 1601 1600 1575)
Cut face: 7(1576 1601 1600 1575 1570 1595 1600) local: 7(47 60 59 46 44 57 59)
Points: 7((0.605439 0.5 -1.5) (0.605439 0.5 -1) (0 0.5 -1) (0 0.5 -1.5) (0 0.328982 -1.5) (0 0.328982 -1) (0 0.5 -1))

Function: void enrichedPatch::calcCutFaces() const
in file: slidingInterface/enrichedPatch/enrichedPatchCutFaces.C at line: 544.

FOAM aborting


I must confess I am still running OpenFOAM-1.0, since I have writen some solvers, and I am very tight on schedule and afraid they might not work imediately with newer version of OpenFOAM... And also I still dont understand many new features...

Unless you really think I should update...

Thanks again,
luiz

[hjasak]

Well, up to you.

What you are looking at is a typical example of a point projection bug in the sliding interface and there are bug fixes both in 1.1 and recently submitted. However, I offer no guarantees that the latest version will run. There are also additional bug fixes in my version, but that's out of reach at the moment. :-)

The only other possibility is for me to try and merge the mesh for you, but you'd have to ask me really nicely. If it fails, I have no time to play with it right now and all you get back is a mesh (I suspect this is not a dynamic mesh case). If there are other ways of producing the mesh you need, I would recommend considering this seriously.

Hmm,

Hrv

[sampaio]

Well,
My mesh is complex (30 blocks, 126 vertices), I dont want you to waste your time... (if you want, I can send you the file, but I will try a couple of things more).

I will try update...

Thanks anyway!
Luiz

[ali]

If I use the sample the mesh with hanging nodes as given by Hrv a few posts above (in this address):

http://www.cfd-online.com/OpenFOAM_D....html#POST1491

to the simple CAVITY problem. I get the following error:

--> FOAM FATAL IO ERROR : keyword leftMerge is undefined in dictionary "./cavityVariableMesh/0/p::boundaryField"

file: ./cavityVariableMesh/0/p::boundaryField from line 42 to line 57.

Function: dictionary::lookupEntry(const word& keyword) const
in file: db/dictionary/dictionary.C at line: 141.

-----------------------------------
If I add (for example) this just to test, I get another error:
--------------------

leftMerge
{
type empty;
}

I get this error:

--> FOAM FATAL IO ERROR : patch 4 not empty type. Patch type = patch

file: ./cavityVariableMesh/0/p::leftMerge from line 62 to line 62.

Function: emptyFvPatchField<type>::emptyFvPatchField
(
const fvPatch& p,
const Field<type>& field,
const dictionary& dict
)

in file: fields/fvPatchFields/basicFvPatchFields/empty/emptyFvPatchField.C at line: 95.
--------------------------

What should I do to solve this problem?

[mattijs]

Have a look at the type of the patches (constant/polyMesh/boundary or in FoamX)

Seems you specified on p that the field type is empty but the leftMerge patch is probably of type 'patch', not 'empty'.

b.t.w. is the leftMerge patch zero size? In which case you can remove it altogether.

[ali]

Thanks Mattijs,

I just want to get Htv's example running. I think it's not correct to set "leftMerge" and "leftMerge". But when I set them as patch, I should set an acceptable type of patch which I don't know what to put as none of the options are proper.

How can I solve this? How can I remove it? Plz let me know thx.

[mattijs]

Remove patch with zero sized faces: edit the constant/polyMesh/boundary file. Remove the patch altogether and adapt the counter at the top of the file (before the opening '(')

[ali]

Here are the files

[ali]

Mattijs,

I did try but no luck, sorry if it seems stupid, but couldn't get it running . The pressure looks unrealistic. The (imaginary) interface is being treated as a wall?

I have attached it here:

cavityVarGrid.zip

Oh in the previous post, I just wanted to test the attachment and couldn't edit or delete it.