[chtrapp]

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

[olwi]

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

[mattijs]

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.

[chtrapp]

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.

[markc]

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

[gmc]

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

[rassilon]

Originally Posted by chtrapp

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:rintStack(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

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

[msbealo]

Any news on this? I'm having similar problems.

Mark

[msbealo]

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

[JohanAdam]

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

[JohanAdam]

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