|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000746||OpenFOAM||[All Projects] Bug||public||2013-02-13 14:03||2015-02-02 09:51|
|Status||closed||Resolution||no change required|
|Target Version||Fixed in Version|
|Summary||0000746: refineMesh stops withtout any error and does not write the new mesh|
|Description||I 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: www.OpenFOAM.org |
| \\/ 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 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 Reproduce||refineMesh|
|Additional Information||This 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.
|Tags||No tags attached.|
Did you try doing a full checkMesh? Namely:
checkMesh -allGeometry -allTopology
And what's the cell count for each type of cell?
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.
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.
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.
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...
|Final remark on the OpenFOAM side: if you want to refine all directions it is better to use refineHexMesh.|
|2013-02-13 14:03||christianfrias||New Issue|
|2013-02-13 14:03||christianfrias||File Added: bugReport-refineMesh.zip|
|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|
||Note Added: 0003649|
||Status||new => closed|
||Assigned To||=> user4|
||Resolution||open => no change required|