View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000746OpenFOAM[All Projects] Bugpublic2013-02-13 14:032015-02-02 09:51
Assigned Touser4 
StatusclosedResolutionno change required 
PlatformLinuxOSUbuntuOS Version10.04
Product Version 
Target VersionFixed in Version 
Summary0000746: refineMesh stops withtout any error and does not write the new mesh
DescriptionI have a mesh created in Pointwise that I want to refine. It was checked with checkMesh, which says that the mesh is OK. However, whenever I try to refine a mesh in all directions (without a dictionary) the program is not able to output any file. The program prompts the following information and then it just stops without any warning or error:

| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.1.1 |
| \\ / A nd | Web: |
| \\/ M anipulation | |
Build : 2.1.1-221db2718bbb
Exec : refineMesh
Date : Feb 13 2013
Time : 08:34:06
Host : "christian-HP-Compaq-6000-Pro-MT-PC"
PID : 14901
Case : /media/FriasData2/OpenFOAMRuns/Wabash-Maier/fromz=2ms=2mToRefinedMesh/finerMesh
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create polyMesh for time = 0

Mesh edge statistics:
    x aligned : number:140619 minLen:1.4821 maxLen:2.58947
    y aligned : number:168894 minLen:1.34488 maxLen:2.49935
    z aligned : number:2902843 minLen:1.73402 maxLen:1.95547
    other : number:6346184 minLen:1.34262 maxLen:3.16384

Refining all cells

3D case; refining all directions

I also tried to refine it in parallel using refinMesh -parallel but I get the same result.

Steps To ReproducerefineMesh


refineMesh -parallel
Additional InformationThis is the first time I am using binary as an output file format in the control dictionary. Could this be the problem? Should I use ascii instead?
The mesh has approximately 3.3 million of points. Is this a number refineMesh is not able to handle?

The size of the mesh file is around 700MB. I can send it to you maybe using ftp. Let me know.

I tried the same program also in one cluster that we have in our campus and the blacklight cluster from XSEDE with the same result.
TagsNo tags attached.
Attached Fileszip file icon [^] (4,717 bytes) 2013-02-13 14:03
txt file icon checkMesh.txt [^] (3,550 bytes) 2013-02-13 21:30 [Show Content]
gz file icon cavity3D.tar.gz [^] (2,006 bytes) 2013-02-16 11:45

- Relationships

-  Notes
wyldckat (updater)
2013-02-13 20:21

Did you try doing a full checkMesh? Namely:
   checkMesh -allGeometry -allTopology

And what's the cell count for each type of cell?
christianfrias (reporter)
2013-02-13 21:31

I have uploaded the results from checkMesh -allGeometry -allTopology. As you can see the mesh is actually bigger than I told you at the beginning (around 5.3 million points). It seems that there is no errors according to checkMesh but refineMesh stops before writing the mesh without any warning or error.

Thank you
wyldckat (updater)
2013-02-13 21:48

What units is your mesh in? Because the bounding box is indicating values of "419885 4.23762e+06 103", which if in meters it would be... a lot!

My suggestions are:
 1. Confirm if you original mesh is in millimetre or metre.
 2. Use transformPoints for moving the mesh closer to the origin of the referential. Ideally for the test, I'd suggest that you align the centre of the geometry with the origin of the referential. Then try refineMesh once again.
 3. Last but not least, if possible, build and test with OpenFOAM 2.1.x.
christianfrias (reporter)
2013-02-14 14:22

Hi Thank you for the suggestions.

The coordinates are in meters but they are projected in UTM. That is why it has huge numbers for the bounding box. I translated the mesh as you told me and used OpenFOAM 2.1.x. I finally could refine that mesh without any problems.
wyldckat (updater)
2013-02-16 11:59

Attached is "cavity3D.tar.gz", a simple example case that helps confirm these kinds of situation. It's based on the "incompressible/icoFoam/cavity" tutorial, modified to 3D and added "Allrun" and "Allclean" scripts.

To run, simply use:
  ./Allclean && ./Allrun

In the "Allrun" script are a few transforms, along with comments of the effects of each transform. The errors become more noticeable when the factor between the size of the domain and the offset centre of the cube becomes greater than about 1000.0, which beyond that leads to serious numerical issues.

The curious part comes when trying to visualize these meshes, because it becomes more and more distorted, the more it is moved from the origin!

In conclusion, this is an end-user situation, because ParaView also has issues with very small objects being represented too far away from the origin of the world referential.

The only thing that might on OpenFOAM's side would be to diagnose this, at least with checkMesh, when the mesh has a "mesh size to offset" factor larger than perhaps 1000. Something like this (pseudo-code):

  mag(boundingBox.centre()) / boundingBox.diag().length() > 1000

although this doesn't take into account very flat meshes...
2015-02-02 09:50

Final remark on the OpenFOAM side: if you want to refine all directions it is better to use refineHexMesh.

- Issue History
Date Modified Username Field Change
2013-02-13 14:03 christianfrias New Issue
2013-02-13 14:03 christianfrias File Added:
2013-02-13 20:21 wyldckat Note Added: 0001910
2013-02-13 21:30 christianfrias File Added: checkMesh.txt
2013-02-13 21:31 christianfrias Note Added: 0001912
2013-02-13 21:48 wyldckat Note Added: 0001913
2013-02-14 14:22 christianfrias Note Added: 0001916
2013-02-16 11:45 wyldckat File Added: cavity3D.tar.gz
2013-02-16 11:59 wyldckat Note Added: 0001922
2015-02-02 09:50 user4 Note Added: 0003649
2015-02-02 09:50 user4 Status new => closed
2015-02-02 09:51 user4 Assigned To => user4
2015-02-02 09:51 user4 Resolution open => no change required