Questions to create polymesh
 

Hello,

I have a problem building a mesh. My intended solver is MRFSimpleFoam. I used the example "MixerVessel2D" in the tutorial as starting point. The disadvantage of the example is that the mesh resolution diminishes with the radius. So, I build a mesh, which does not have that disadvantage. Since the stirrer geometry is also quite more complex, I decided to build a blockMeshDic file entirely on my own. There is no grading, but everything is 1 1 1 simplegrading.

The resulting blockMeshDic file is at minimum 150 MB big up to 1 GB. This did not please the blockMesh utility, but lead to a system crash. I filed a bug report to OpenFoam and was advised to write out the polymesh directly, since 90 % of that work is already done.

I looked into this option, but there is no manual how to write the polymesh. Instruction by OpenFoam are very basic. So, I looked at a compiled case (compiled by blockMesh) and tried to identify how blockMesh builds a polymesh. There I have some questions:

1. Is there a manual available to build the polymesh in the 1st place?
2. The file "points" seems basically to be the same as the vertice definition in m with 10 valid digits. But the order between that chosen in the source file blockMeshDic and that generated by blockMesh differs. Why? Does it matter if I keep my original order? Is there any logic why the order is changed?
3. Once the file "points" is built, the file "faces" is pretty much straight forward as is the file "owner". "owner" seems to patch the faces together that then is a cell. However I do not get what the numbers in "neighbours" mean. To what do they refer? Every face has obviously plenty of neighbors (above, below, right, left, before and below at least). What is the point of this file?
4. There is a file called cellZones, which has an entry of 0 to some big number. I have put the blocks into order (rotor first, than stator blocks). Are these block numbers from blockMeshDic?

If anybody could help, I would apreciate.:eek:

Greetings Daniel,

I saw your post and bug reports several days ago, but I was unable to look into this sooner, nor have I been able to confirm things yet... but I think that Discretizer's code might help you:

• http://www.discretizer.org/
• http://sourceforge.net/scm/?type=svn&group_id=160770

It's programmed in Ruby and the main program helps design the geometry and take into account the resulting mesh at the same time. It pretty much only generates meshes for OpenFOAM. If you look into the code, you might be able to figure out how to solve your problem.

The author of Discretizer, Björn Bergqvist, might also be able to help you: http://www.discretizer.org/node/6

Good luck!
Bruno

thanks for reply
 

Hello Bruno,

Thanks for your input. I had looked into discretizer. It would mean that I have to build my mesh from ground up again whereas I have created the blockMeshDic file already. All I need is that final step to get the polymesh. But you suggested to look into the source code trying to understand what the program does. So far, just looking at the result text files, I was always able to understand what is required. This is how I had built the blockMeshDic file after all using an Excel sheet and some visual basic code to handle the enormous amount of generated data. The polymesh files are not so straight forward as said in the documentation of OpenFoam. I think it is because of the cellzones "rotor" which is necessary to define for MRF problems. The m4 utility, which is in the tutorial, is pretty much useless since it builds a blockMeshDic file and than calls blockMesh as one would do anyway.

I will now try to use the mergeMesh utility after having created several submeshes that blockMesh is still able to handle. I let you know if this works. My fear is that I might run into the same troubles again, since I do not know if mergeMesh is more powerful than blockMesh, since it will have to handle the same amount of data again the advantage being that it uses polymesh data and not the blockMeshDic file to generate the unified mesh.

I will post again if I succeed.

Regards,

Daniel

Hi Daniel,

A colleague of mine told me today:
Best regards and good luck!
Bruno

Hi Bruno,

Thanks, this is an idea, but I do not have Star-CD. However, I did a first trial using mergeMeshes and it worked increditably fast (compared to blockMesh). I found a small mistake on my mesh and also have to remove the interface between the two meshes. This will take at least until next week. I will post if it works.

Have a nice weekend,

Daniel

Hi Daniel,

Sorry, I was in a hurry and hoped you would have gotten the idea. I'll try to make it more clear:

1. With a small test case, you can convert an existing OpenFOAM mesh by running foamToStarMesh. It will generate a few files, two of which have the extensions ".vrt" and the ".cell".
2. See how the mesh is defined on those files, which should prove to be more intuitive than OpenFOAM's mesh.
3. Then when you've got something to work with in this format, you can convert back to OpenFOAM by running star4ToFoam! For more:
   Code:

   ---

   star4ToFoam -help

   ---

4. You might even want to then pick up on the code of star4ToFoam to do your own converter!

Nonetheless, it's good to know that mergeMesh can do a very good job on this issue!

Best regards,
Bruno

star4toFoam
 

Hi Bruno,

Your idea seems worth a trial especially if I want to generate even larger meshes (the case I am working on is the smallest that I can imagine, still it is about 1 GB).

Currently, since I am very close to the solution I want, I have to put your idea beside, since I really need results fast. The next step is an extension of my current design. So, the mergeMeshes tool should work too.

As promissed, I will post if I succeed. If I use your approach, I will post too. But this will take a couple months.

Regards,

Daniel

Hi Bruno,

Finally I got my mesh! I tried the mergeMeshes utility, but since the original mesh was cut into 2 pieces, each of the pieces had an undefined patch on one side. BlockMesh set this interface to defaultFaces. Unfortunatly this new patch is not set at the beginning of the patch list, but at the end. So, deleting this patch in the boundary file leads to undefined faces since they are just ignored. Obviously one can copy these faces over, but my faces file is very big, meaning this will be difficult. I propably would have to define a new patch and putting it before "rotor" and "stator" in the blockMeshDict file. Still, I do not like this, since the boundary faces between the two merged meshes will be apperaing at the end of the internal faces list although they are situated in the center. I do not know if this is a problem, but I want a performend mesh to speed up CFD calculation.

I had a small error where the mesh was undefined, set by blockMesh to defaultFaces. I corrected this error. I decided then to rerun blockMesh on the entire mesh once again hoping that will work this time. I shut off all cores except one to stabilize blockMesh. It ran 3 days, but ultimatly I got the mesh created.

Thanks for the support. I know now what to do next time I get the same problem.

Regards,

Daniel

PS: Now MRFSimpleFoam runs, but makes mistakes. I will post this separatly since this problem seems unrelated to the mesh generation.

Hi Daniel,

You're welcome and I'm glad you got it working!
3 whole days... I assume with the case with 150MB worth of "blockMeshDict"? The people at SGI/OpenCFD might like to know that ;)

Best regards,
Bruno

I have polymesh files generated for a simulation using pointwise. It's a pretty fine mesh. How can I write the blockmeshdict file for the same?
Is it possible in anyway to convert internally the data from polymesh into blockmeshdict?

Hi poyilil,

You do not need a blockMeshDic file if you already have a polyMesh. The blockMeshDic file is the source file to generate a polyMesh out of basic geometric data. This file has to be compiled to polymesh files. After this is done, you can delete it without harming the CFD calculation (even though I would not recommend to do so).

The polyMesh files have names like "owner", "neigbour", "points", "faces" and "boundary". Only the "boundary" file needs to be looked at and configured, I would guess, if you use a third party product. There are a number of different boundary types if you look into the documentation, the most basic one is "wall".

Good luck,

Daniel

Thank you so much Daniel :)