CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Other Meshers: ICEM, Star, Ansys, Pointwise, GridPro, Ansa, ... (http://www.cfd-online.com/Forums/openfoam-meshing-other/)
-   -   CheckMesh Error when importing from Pointwise (http://www.cfd-online.com/Forums/openfoam-meshing-other/119131-checkmesh-error-when-importing-pointwise.html)

jp3g12 June 10, 2013 12:23

CheckMesh Error when importing from Pointwise
 
Hello,

When I do a checkMesh in openfoam after importing a grid from pointwise I get he following error
Code:

Create time
Create polyMesh for time = 0
Time = 0
Mesh stats
    points:          269930
    internal points:  0
    faces:            533656
    internal faces:  263720
    cells:            132896
    boundary patches: 6
    point zones:      0
    face zones:      0
    cell zones:      0
Overall number of cells of each type:
    hexahedra:    132896
    prisms:        0
    wedges:        0
    pyramids:      0
    tet wedges:    0
    tetrahedra:    0
    polyhedra:    0
Checking topology...
    Boundary definition OK.
 ***Total number of faces on empty patches is not divisible by the number of cells in the mesh. Hence this mesh is not 1D or 2D.
    Cell to face addressing OK.
    Point usage OK.
    Upper triangular ordering OK.
    Face vertices OK.
  *Number of regions: 4
    The mesh has multiple regions which are not connected by any face.
  <<Writing region information to "0/cellToRegion"
Checking patch topology for multiply connected surfaces ...
    Patch              Faces    Points  Surface topology                 
    flap                168      336      ok (non-closed singly connected) 
    frontAndBack        268080  269930  ok (non-closed singly connected) 
    inlet              684      1370    ok (non-closed singly connected) 
    main                324      648      ok (non-closed singly connected) 
    outlet              480      962      ok (non-closed singly connected) 
    slat                200      400      ok (non-closed singly connected) 
Checking geometry...
    Overall domain bounding box (-15 -1 -15) (20 0 15)
    Mesh (non-empty, non-wedge) directions (0 0 0)
    Mesh (non-empty) directions (0 0 0)
 ***Number of edges not aligned with or perpendicular to non-empty directions: 533922
  <<Writing 269926 points on non-aligned edges to set nonAlignedEdges
    Boundary openness (-1.11464e-17 -4.12034e-15 1.11487e-17) OK.
    Max cell openness = 4.54419e-13 OK.
    Max aspect ratio = 0 OK.
    Minumum face area = 1.46807e-10. Maximum face area = 3.66808.  Face area magnitudes OK.
    Min volume = 1.46807e-10. Max volume = 3.66808.  Total volume = 974.817.  Cell volumes OK.
    Mesh non-orthogonality Max: 89.6586 average: 22.6842
  *Number of severely non-orthogonal faces: 2318.
    Non-orthogonality check OK.
  <<Writing 2318 non-orthogonal faces to set nonOrthoFaces
    Face pyramids OK.
 ***Max skewness = 15.2658, 36 highly skew faces detected which may impair the quality of the results
  <<Writing 36 skew faces to set skewFaces
    Coupled point location match (average 0) OK.
Failed 2 mesh checks.
End

I am mostly concerned with the "Total number of faces on empty patches is not divisible by the number of cells in the mesh. Hence this mesh is not 1D or 2D." also it worries me that it says " The mesh has multiple regions which are not connected by any face."

The mesh I am trying to import is a multi-element wing, with different domains. When I set the BCs in pointwise for OpenFOAM is there a way to prescribe something on the interfaces between the multiple regions? is this a cause of concerned?

I also don't understand why is says that the grid is not 1D nor 2D.

Any help is appreciated!

Thank you!

james

wyldckat June 10, 2013 13:40

Greetings James,

AFAIK, OpenFOAM does not work in the same way as some other CFD applications, when it comes to the topic of "interfaces". It prefers to have things more well defined, e.g.:
  • For MRF, it relies on "cellZone"'s to know where the rotating part should be. In other words, there is only one mesh region, of which a part of it is specially selected and identified as a "cellZone"; therefore, interfaces as not used between the rotating part and the fixed part.
    • If I remember correctly, porous zones work the same way.
  • Then there is the multi-region definition that OpenFOAM uses for solvers like chtMultiRegionFoam. This relies on actually splitting the single region into explicit separated mesh regions, with explicit interfaces between patches.
  • Last but not least, there are the "faceSet/cellSet"'s which are used for simply selecting faces/cells and then we can use the name associated to the selection to do some post-processing or mesh manipulation.
So... which kind of "interface" are you in fact looking for in OpenFOAM? ;)

Best regards,
Bruno

jp3g12 June 10, 2013 14:49

Hello Bruno,

thanks for the quick reply,

Well it seems as though my mesh has been constructed as a multi-block mesh. basically what happens is that there are 4 different blocks (one for the flap of the wing, one for the slat, one for the main element and another one for the rest). I presume OpenFOAM is talking about the interfaces between each of the blocks which compose the mesh.

Right now in pointwise I am just "ignoring" those blocks if you wish, and when it comes to setting up the boundary conditions, all I do is to define the inlet, outlet, walls and front and back (which I assign it to everything that is not the inlet, the outlet or the walls).

I could send you the .p3d file if you wish to take a look at it. Any suggestions?

Thanks,

James

wyldckat June 10, 2013 14:52

Hi James,

Then I guess there are at least 2 possible solutions:
Best regards,
Bruno

jp3g12 June 10, 2013 15:31

Hi Bruno,

Yeah I think option 1 is not really an option because I tried that the other day and Pointwise refuser to help me out!!! It is very weird. I will take a look at the other thread and give it a shot!

Also let me ask you could the other error "Total number of faces on empty patches is not divisible by the number of cells in the mesh. Hence this mesh is not 1D or 2D" in any way be related to me having multiple blocks?
Thanks for the help!

James

wyldckat June 10, 2013 16:18

Hi James,

Quote:

Originally Posted by jp3g12 (Post 433209)
Also let me ask you could the other error "Total number of faces on empty patches is not divisible by the number of cells in the mesh. Hence this mesh is not 1D or 2D" in any way be related to me having multiple blocks?

It does look like it. You could try assigning patches to the interfaces instead and then export... but I'm guessing Pointwise will complain as well.

Best regards,
Bruno

jp3g12 June 10, 2013 16:20

Thank you Bruno!! I will try it and hopefully it will work ;)

jp3g12 June 15, 2013 04:49

2 Attachment(s)
Hi Bruno,

So I tried your suggestions and they did not work. The problem that I am having currently (see attached images) is that when I set the BCs in pointwise to convert the mesh to OpenFOAM format, I have about 4 parts (highlighted in red in any of the images) that are neither part of the geometry nor 'empty' patches. As you can see they are the boundaries of the blocks. These extend to the end of the domain.

When I tried the stitchMesh it did not work (I always get an error telling me I have not define a proper 'type' for these entities, and by type I mean patch, empty and things like that)...

I am pretty stuck with it, because these boundaries have nothing to do with the geometry and they are only interfaces between blocks!

Any suggestions as to how to proceed/fix this issue?

Thanks for the help!

James

wyldckat June 15, 2013 09:09

Hi James,

Could you created a (very) small example with the mesh already in OpenFOAM format, so I can try this myself?

If the compressed case is too big for the forum, try using Dropbox, SkyDrive, Google Drive or something like that.

Best regards,
Bruno

jp3g12 June 15, 2013 09:55

Hi bruno!
I have uploaded the case with the mesh in OpenFOAM format to Dropbox. I left the undefined interfaces (Highlighted in red on the previous post) untouched.

https://www.dropbox.com/s/fhihp0waik...multi.tar.gz?m

Thanks for your help,

James

wyldckat June 15, 2013 14:58

1 Attachment(s)
Hi James,

OK, attached is a package that provides additional files for your case, which attempts to split the regions apart, rename the interfacing patch into several patches and then put it back together.
Problem is that it doesn't work :( But I think I understand why.

First, an explanation on how to use the attached file:
  1. Place the attached file "toAddToCase.tar.gz" inside your case folder and unpack it. The reason is because this file is a tarbomb, in the sense that the contents of the package are not inside a folder themselves.
  2. The following files were added:
    • Allrun - script for running the whole messy split/rename/merge business.
    • constant/toleranceDict - needed for stitchMesh*
    • system/createPatchDict - needed for redefining the "Unspecified" patch to an actual patch.
    • system/stitchMeshMultiPatchDict - needed for the application stitchMeshMultiPatch, which is explained at http://www.cfd-online.com/Forums/ope...tml#post433137 post #10.
  3. So, once stitchMeshMultiPatch is built (or comment out the last line in the Allrun script), run:
    Code:

    ./Allrun
  4. In essence, what it does is:
    1. Convert "Unspecified" to a proper patch named "internalPatches".
    2. Split the mesh into regions, so that we're able to rename the patches on each region (domain).
    3. Rename "internalPatches" depending on domain.
    4. Clone the case to a separate folder.
    5. In the cloned case, move the "domain0" mesh to the main mesh and take out the other domains.
    6. Merge each of the other 3 domains from the original case.
    7. And try to stitch them together.
Why this doesn't work is rather simple: the patches on each sub-domain still go full circle, in the sense that a single patch is actually able to touch 2 other patches, instead of just one. And from what I can figure out, stitchMesh was designed for stitching 1:1 patches, even though they might have different faces and points.

So, what you need to at least do is: extract in Pointwise the actual connections between these regions, into STL or OBJ file format. This way it'll be possible to use surfaceToPatch to assign the faces for these 1:1 patches.


There is another way, but highly complicated and I didn't bother trying it myself. There is an application in OpenFOAM named autoPatch. If you run:
Code:

autoPatch 15 -overwrite
it will scrap the old patches and create new ones based on the angle "15", assigning names like "auto0", "auto1", "auto2" and so on. Problem is that these may not be accurate and may not lead to good 1:1 patches... maybe unless this is done individually on the sub-domains... but still, it's very complicated.

Best regards,
Bruno

jp3g12 June 15, 2013 15:12

Wow!!

Well I will give it a try for sure!! Thanks for Spending your time trying to find a solution. I appreciate it a lot!!

Will let you know how it goes but I will definitively need some time ;)

Thanks a lot !!

James

rmatus June 28, 2013 15:58

Change unspecified to wall in Pointwise?
 
Hi James:

From your pictures it looks like the unspecified patches in Pointwise are on the tunnel walls. Have you tried setting them to a wall BC in the CAE, Set BCs panel?

If they are not on the tunnel walls and are instead interblock connections, Pointwise should automatically recognize them as connections and set the OpenFOAM patches that way. If that is not happening, I would use the Grid, Merge tool in Pointwise to find out why they are not matching.

Hope this helps,
Rick

jp3g12 June 29, 2013 08:07

Hi Rick,

Yeah I tried to do that but it really did not work at all (because at the end you end up having a flat plate attached to the trailing edge of every element and therefore you get an unreasonable result).

I did manage to get the OpenFOAM mesh working (I had to split the domain into many more subdomains to get rid of red stuff). My problem now is that the mesh contains high AR and skewed cells and it is not working :(

Cheers,

James

rmatus July 1, 2013 09:26

James:

I'd be happy to take a look at the grid and see if I can make some improvements if you want to send it to me.

Rick

jp3g12 July 1, 2013 10:19

Hi Rick,

Thanks for helping me out. Here is the case,

https://www.dropbox.com/sh/atig1aq2isk0kqt/6VoarfDsQn

I basically tried to run the case in steady mode with S-A model but it did not work. I have been assuming the cause for the problem is the high AR and skewed cells! The case gives a floating point exception after a while.

Thanks for the help!

James

rmatus July 1, 2013 10:30

Hi James:

Actually, I was hoping you could send the Pointwise project (.pw) file, so I could try to correct any problems there. Could you send that also?

Thanks,
Rick

jp3g12 July 1, 2013 10:34

Oh I see!

I will do that tomorrow since I am not at the uni at the moment!

I will send you the original file for you to take a look at it if you wish.

Thanks,

James

jp3g12 July 1, 2013 17:45

Hi Rick,

I have managed to upload the .pw file onto the following link

https://www.dropbox.com/sh/atig1aq2isk0kqt/6VoarfDsQn

As I said earlier, the main problems of the mesh appear to be the cell skewness and the Aspect ratio. It think that is what is causing the problems in OpenFOAM.

Thanks for the help!!!

James

rmatus July 3, 2013 16:45

James:

Here is an updated Pointwise mesh. https://www.dropbox.com/s/ofuciuznlw...-smoothed-1.pw

I made a few changes to the original mesh:

1. Merged some duplicate connectors. This was causing the error about the number of faces on empty patches.

2. Ran the Pointwise elliptic solver to try to reduce the number of skewed cells. The skewed cells were all at the sharp corner at the base of the cusp of the cove region on the slat. There are still 8 skewed cells there, and I don't think they can be cured unless the grid topology in that region is changed. For an idea of a good topology to use, check out Figure 6 in this article about meshing an airfoil for aeroacoustics.

3. Ran the elliptic solver on the mesh around the main wing element to reduce the number of high aspect ratio cells. There are still 3 left toward the middle of the upper wing surface. To eliminate them either the chordwise spacing needs to be reduced locally or the spacing normal to the wall needs to be increased. I would recommend decreasing the chordwise spacing, but I do not have the geometry so I could not do this and maintain the correct wing shape.


Hope this helps.
Rick


All times are GMT -4. The time now is 15:59.