I am building a very much simp
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.
What am I doing wrong?
Hi Christian, I don't have
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?
It might work as long as you d
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.
I just checked if maybe I had
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.
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.
how use refineMeshDict
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:
Could someone help us find information about the significance of these parameters?
Thanks. Ana and Sonia
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.
Any news on this? I'm having similar problems.
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.
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?
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*
|All times are GMT -4. The time now is 16:07.|