[kupiainen]

I have a good and kosher blockMeshDict, which describes my mesh. I have doubled the number of grid points in all directions, and blockMesh works fine. Now I wanted to make another doubling of grid points, and tried to run blockMesh, but got the following cryptic message and the program died:
/*---------------------------------------------------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.0.2 |
| \ / A nd | Web: http://www.openfoam.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/

Exec : /afs/nada.kth.se/home/nada/marcok/OpenFOAM/OpenFOAM-1.0.2/applications/
bin/linuxIA64I64Opt/blockMesh . base3
Date : Apr 14 2005
Time : 16:35:47
Host : h05n23.pdc.kth.se
PID : 869
Root : /afs/nada.kth.se/home/nada/marcok/prj00
Case : base3
Nprocs : 1
Create database


Reading block mesh description dictionary

Creating block mesh

Creating blockCorners

Creating curved edges

Creating blocks

Creating patches

Creating block mesh topology

Default patch type set to empty

Check block mesh topology

Basic statistics
Number of internal faces : 101
Number of boundary faces : 50
Number of defined boundary faces : 50
Number of undefined boundary faces : 0

Checking patch -> block consistency

Creating block offsets

Creating merge list .

Creating points

Creating cells

Creating patches

Creating mesh from block mesh

Default patch type set to empty



What can be the problem? Is there some limitation?
best regards

[mattijs]

What is your cryptic message? All seems ok. Does it core dump and if so what if you compile blockMesh with debugging and traceback in a debugger?

[kupiainen]

It does not core dump. In fact the trouble is that there is no output i.e. no grid. It seems that everything is fine, but still no grid. By the way the gridsize will be something around 8 million cells, can this cause problems?

[henry]

Are you running 32bit or 64bit? You can't generate 8e6 cells with only 32bit addressing, the maximum is about 2e6 but you can with 64bit.

[kupiainen]

How do I check if I'm running 32bit or 64bit? The machine sure supports 64bit, but I'm not sure if I compiled the code with the right flags.

[henry]

There is an optional environment variable to switch between 32bit and 64bit on machines that support both, $WM_64, which is documented in the README file. What do you have it set to? If you have it set and you are on an AMD64 machine $WM_OPTIONS will be linuxAMD64Opt otherwise it will be linuxOpt and you are running 32bit.

[kupiainen]

I'm running 64bit, since
setenv WM_64 yes
and
echo $WM_OPTIONS
linuxIA64I64Opt.

I have only one time directory 0.075 present, does this have to be named 0?

[henry]

No there is nothing fundamental about the 0 directory unless you have specified in the controlDict that the code will start from time 0.

[kupiainen]

Now I understand, why the program crashes...
I have 8GB of memory available, and blockMesh requires more for 8million cells. Is there a parallell blockMesh?
This would mean that 1cell = 1000B, is this really reasonable?

[eugene]

Does this include swap space? If you have a 64-bit machine, simply increase your swap. Running blockMesh might take a bit longer, but you shouldn't have memory problems.

In any case, blockMesh uses less than 1kB per cell (~750 bytes when I last checked), so your problem might be elsewhere. Even if it was a memory issue, you would get an error message stating this. The fact that the code exits without any warnings or errors messages is HIGHLY unusual.

Make sure you execute "ulimit -c unlimited" in your login shell, run the code again and check whether it has generated a core dump. I dont even want to begin to speculate what could cause a crash with no error message or core dump.

For the record, I have generated 32 million cell blockMeshes without any problems.

There is no parallel blockMesh. As to why it uses so much memory, the source code is in OpenFOAM-1.1/applications/utilities/mesh/generation/blockMesh/
I'm sure you could significantly reduce the memory overhead if you were prepared to live without some of the built in checks.

[hjasak]

Hi,

I've seen and fixed this before - it is a silly error in mesh reference setup on creation of mesh modifiers. Not sure why it didn't make it into the release...

However, the fix (compared to the 1.2 release) is a bit spread out so I've no idea how to pass it over short of packing up several libraries that you would have to compile locally (I suspect this will turn up more often with multiple mesh modifiers).

By the way, is the mesh itself any use to you (that's easy to E-mail across) or were you after something more complex?

Hrv

[hjasak]

Forgot to say:

- Rolando, you should really define the outside patches, otherwise the complete outside surface endds up in a patch of type empty by default, which is no too healthy.

- for all those out there looking at the mesh using paraFoam, the wiggly lines at the block boundaries are not real. The cells are actually rpoper polyhedral but paraview cannot deal with them so they need to be decomposed into "allowed" shapes on the fly

- dxFoam does not have this problem = you only get the real mesh lines. Also, if I remember correctly, the version of dxFoam I've sent out for foam-1.1 works OK with the new version as well.

Enjoy,

Hrv

[rolando]

Hi Hrvoje,
I tried to create a mesh, that´s a little bit more complex and there I encountered the problem. The case above is just a simplification, that I´ve chosen to shortly place the problem in the discussion group.
Would it be possible to get the fix? And would it be possible for me to handle it?
Do you have any other ideas, how I can overcome that problem? I tried several things, as creating each mesh block separately and merging them by "mergeMeshes". But I didn´t meet with success.

Regards
Rolando

[rolando]

I was to slow for your second message.
Thanks for the hint.
I left the outside patches in the above example to keep it short. In my real (complexer) mesh I use them.

[hjasak]

All I can offer is access to my development version, pending the inclusion of bug fixes into the release.

Apologies,

Hrv

[ali]

I have made a variable mesh, two-patch cavity case, the left and right patches have different number of grids. It doesn't give acceptable results, even if I set the left and right grids the same resolution.

What I have done wrong? I appreciate any help.

cavityVarMesh.tar.gz

[mattijs]

Hi Rolando,

I tried your blockMeshDict and it works fine in 1.2, also under valgrind. Are you running 1.2?

[rolando]

Thanks Hrvoje,
I´d be grateful, if you can make me accessible your version.

Hi Mattijs,
I´m still running 1.1, because I don´t get the 1.2 version running on my machine. My linux version doesn´t provide the proper glibc. I tried to compile OpenFOAM yesterday, but I didn´t succeed so far.

Rolando

[hjasak]

Dear Ali,

Ias I have suspected, there is absolutely nothing wrong with the code (again!). Attached is the image of the solution from your case



Could you please have a careful look at it and tell me precisely why you think there is something strange about it. Also, please note that the case runs out of box exactly as you have provided it; the only difference is that it converges in about 10 s simulation time rather than the 0.5 s in the tutorial.

May I also suggest much more care if in the future you decide to report problems with the code - reporting issues that are not there or are a result of poor setup or understanding leaves a bad image of the code which it does not deserve (wastes my time as well!)

Regards,

Hrv

[rolando]

Dear Hrvoje, dear Mattijs,
thanks for your help. I got version 1.2 running on my machine. Now the mesh generation seems to work fine.

Rolando