|
[Sponsors] |
DynamicRefineFvMesh dies on snappyHexMesh generated grid |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
January 29, 2009, 12:10 |
I am building a very much simp
|
#1 |
New Member
Christian Trapp
Join Date: Mar 2009
Posts: 7
Rep Power: 17 |
I am building a very much simplified simulation of smoke coming out of a chimney. The case runs fine with interDyMFoam when using a staticFvMesh. Whenever I try to run it with a dynamicRefineFvMesh, the case aborts with the following message:
Starting time loop Courant Number mean: 0.0877711 max: 0.504 deltaT = 0.25 Time = 0.75 Selected 0 cells for refinement out of 20000. Only call if constructed with history capability#0 Foam::error::printStack(Foam:: Ostream&) in "/usr/local/fgtools/OpenFOAM/OpenFOAM-1.5/lib/linuxGccDPOpt/libOpenFOAM.so" #1 Foam::error::abort() in "/usr/local/fgtools/OpenFOAM/OpenFOAM-1.5/lib/linuxGccDPOpt/libOpenFOAM.so" #2 Foam::hexRef8::getSplitPoints() const in "/usr/local/fgtools/OpenFOAM/OpenFOAM-1.5/lib/linuxGccDPOpt/libdynamicMesh.so" #3 Foam::dynamicRefineFvMesh::selectUnrefinePoints(do uble, Foam::PackedList<1> const&, Foam::Field<double> const&) const in "/usr/local/fgtools/OpenFOAM/OpenFOAM-1.5/lib/linuxGccDPOpt/libdynamicFvMesh.so" #4 Foam::dynamicRefineFvMesh::update() in "/usr/local/fgtools/OpenFOAM/OpenFOAM-1.5/lib/linuxGccDPOpt/libdynamicFvMesh.so" #5 main in "/usr/local/fgtools/OpenFOAM/OpenFOAM-1.5/applications/bin/linuxGccDPOpt/interDyMFoam" #6 __libc_start_main in "/lib/tls/libc.so.6" #7 Foam::regIOobject::writeObject(Foam::IOstream::str eamFormat, Foam::IOstream::versionNumber, Foam::IOstream::compressionType) const in "/usr/local/fgtools/OpenFOAM/OpenFOAM-1.5/applications/bin/linuxGccDPOpt/interDyMFoam" From function hexRef8::getSplitPoints() in file polyTopoChange/polyTopoChange/hexRef8.C at line 4666. FOAM aborting What am I doing wrong? Greetings, christian simplifiedRefining.tar.gz |
|
February 1, 2009, 16:38 |
Hi Christian,
I don't have
|
#2 |
Member
Ola Widlund
Join Date: Mar 2009
Location: Sweden
Posts: 87
Rep Power: 17 |
Hi Christian,
I don't have the answer to your problem, but I join you in hoping you find some feedback from the forum... Since both dynamicRefineFvMesh and snappyHexMesh seem to use the same refinement/coarsening tools (i.a. the polyTopoChnager hexRef8), one would think that they are compatible. I am hoping to use the same approach in a later stage of a current project. Does anyone else have experience of succesfully combining snappyHexMesh meshes with the dynamicRefineFvMesh class? Any fundamental reasons to believe it wouldn't work? /Ola |
|
February 3, 2009, 04:48 |
It might work as long as you d
|
#3 |
Senior Member
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,419
Rep Power: 26 |
It might work as long as you don't have any layers - they mess up the refinement information (pointLevel, cellLevel). The dynamicRefineFvMesh tries to work out from those two files what cells can be refined.
|
|
February 3, 2009, 09:06 |
I just checked if maybe I had
|
#4 |
New Member
Christian Trapp
Join Date: Mar 2009
Posts: 7
Rep Power: 17 |
I just checked if maybe I had forgotten to switch the layer addition off (which would be just me). Dissapointingly I found that it is switched off.
To be sure, I checked the number of cells before and after running snappyHexMesh (and found it to be constant). So I'm a bit sorry here, since it would have been nice if the solution had been to simply remove the layers. Greetings, christian. |
|
March 26, 2009, 05:54 |
|
#5 |
Senior Member
Mark Couwenberg
Join Date: Mar 2009
Location: Netherlands
Posts: 130
Rep Power: 17 |
Hello All,
I get a similar error message on a mesh created with blockMesh and snappyHexMesh. I use turbDyMFoam and want to refine based on the volScalarField epsilon. It seems like a refinement actually occurs, the log file gives >>> Selected 5 cells for refinement out of 59607. Refined from 59607 to 59642 cells. <<< But then the solver crashes, giving the same stacktrace is presented above, with the error message: >>> Only call if constructed with history capability <<< I played around with settings in the refineMeshDict, without success. Any comments? Brgds, Mark |
|
March 26, 2009, 07:05 |
how use refineMeshDict
|
#6 |
New Member
sonia esteban
Join Date: Mar 2009
Posts: 2
Rep Power: 0 |
Hi all
We read your last comment about how use refineMeshDict We are working with interDyMFoam recently,using only refineMeshDict and get refined/coarsed our mesh based on the volScalarField Temperature (modified maxRefinement and maxCells ). But we like more information about the meaning of this parameters: unrefineLevel 10; nBufferLayers 1; Could someone help us find information about the significance of these parameters? Thanks. Ana and Sonia |
|
January 12, 2011, 23:56 |
|
#7 | |
Member
Join Date: Mar 2009
Location: Sydney, New South Wales, Australia
Posts: 42
Rep Power: 17 |
Quote:
Hi! Did you ever solve this problem? I am hoe encountering the exact same error, and would love to know how/if you overcame it I am trying to use snappyHexMesh and interDyMFoam together with no success. Cheers, R |
||
April 13, 2011, 05:36 |
|
#8 |
New Member
Mark Beal
Join Date: Feb 2011
Posts: 24
Rep Power: 15 |
Any news on this? I'm having similar problems.
Mark |
|
April 13, 2011, 07:11 |
|
#9 |
New Member
Mark Beal
Join Date: Feb 2011
Posts: 24
Rep Power: 15 |
I made a little headway on this and thought I'd share my solution. This is mostly guesswork and following similar threads on here. I was hoping to see how a refinement layer around the water/air interface of a boat in a flow developed using dynamicRefineFvMesh, which I mostly copied from the damBreakWithObstacle case. I set up my case using a simple 20x20x20 (ish) box, used snappyHexMesh to import my hull shape. The case worked well with interFoam before I made the changes. I had similar problems to those described above, so here is my solution.
1) I delete the refinementHistory file from polyMesh folder. This fixed the "Only call if constructed with history capability" problem. 2) Changing the fvSolutions file so that cacheAgglomeration = false for all solvers. I tested this further and just turning the p_rghFinal PCG/GAMG solver to false fixed the problem for the first few iterations. This solved the "field does not correspond to level 0 sizes: field = 19860 level = 10683" problem 3) Also, I turned off the surface layers in the snappyHexMeshDict. This was suggested on here, but I didn't test it's effectiveness. I'm still not able to run in parallel as I get the following error, "Number of cells in mesh:2666 does not equal size of cellLevel:10683 This might be because of a restart with inconsistent cellLevel." but for the purposes of investigating the interface refinement region this might not be necessary. I hope this helps someone. Mark |
|
October 1, 2012, 08:00 |
|
#10 |
New Member
Johan
Join Date: May 2012
Posts: 7
Rep Power: 14 |
Hi everyone
I am also having the same problem with snappy and dymanicRefineFvMesh. Did anyone perhaps test other mesh generators? If it is only snappy, would a dirty work around by importing and exporting the mesh maybe be possibility? Johan |
|
October 4, 2012, 06:30 |
|
#11 |
New Member
Johan
Join Date: May 2012
Posts: 7
Rep Power: 14 |
Hi everyone
To get adaptive mesh refinement working with snappyHexMesh, I found I had to delete the following files from constant/polyMesh after creating the mesh $ rm constant/polyMesh/cellLevel $ rm constant/polyMesh/pointLevel $ rm constant/polyMesh/refinementHistory $ rm constant/polyMesh/surfaceIndex $ rm constant/polyMesh/temp* Cheers Johan |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
DynamicRefineFvMesh dies on snappyHexMesh generated grid | chtrapp | OpenFOAM Running, Solving & CFD | 0 | January 29, 2009 12:07 |
How to import grid generated using ICEM/CFD | Harry | Siemens | 2 | April 17, 2006 00:01 |
Use of grid generated by GAMBIT | ramp | Main CFD Forum | 5 | July 8, 2005 13:24 |
StarWatch Daemon always dies! | Jiaying Xu | Siemens | 14 | December 9, 2002 21:52 |
Dead cells created on edges when a grid file is generated in GAMBIT and imported into FLUENT4 | Isaac Manohar Ch. | FLUENT | 1 | June 2, 2000 04:58 |