[eberberovic]

Dear all,

I am using OpenFOAM-1.5-dev (svn r. 1051), compiled on openSuSE 10.3, 64 bit. There seems to be a problem with interDyMFoam when using dynamic mesh refinement (dynamicRefineFvMesh). The tutorial damBreakWithObstacle always breaks down on floating point after a few time steps (velocity and gamma become too large).

I have found out the following:
1) when I run it with interFoam, there is no problem at all.
2) when I run it with interDyMFoam without refinement (using staticFvMesh), there is also no problem at all.

But as soon as I want to calculate with automatic refinement, I get the floating point. I have tried various settings for the solvers without success. Does this mean that there might be some errors somewhere in the libraries (mesh refinement, recalculation of relative/absolute fluxes ... )?

I would really appreciate any help on this. Thanks a lot in advance.

There is also a minor issue that subsetted mesh and fields are written to the setSubset folder within a time directory (e.g. 0.001/setSubset), and the application cannot find them, so they need to be copied from the setSubset folder one level up to the time directory.

Best regards,
Edin.

[hannes]

Hello Edin,

I had a look through the source code of dynamicRefineFvMesh.C and it seems to me that the function readDict() gets never called. This results in an empty list "correctFluxes" (although there is an entry in constant/dynamicMeshDict) and in turn the code that maps the fluxes is omitted.

I have added a call of readDict() at the beginning of the constructor of dynamicRefineFvMesh and then interDyMFoam runs for some time and gamma remains bounded between 0 and 1.
But the solver still crashes. The stack trace then is:

#0 Foam::error::printStack(Foam:stream&) in "/home/hannes/OpenFOAM/OpenFOAM-1.5-dev/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/home/hannes/OpenFOAM/OpenFOAM-1.5-dev/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 ?? in "/lib/libc.so.6"
#3 Foam::pos(Foam::Field<double>&, Foam::UList<double> const&) in "/home/hannes/OpenFOAM/OpenFOAM-1.5-dev/lib/linux64GccDPOpt/libOpenFOAM.so"
#4 Foam::tmp<foam::geometricfield<double,> > Foam::pos<foam::fvspatchfield,>(Foam::GeometricFie ld<double,> const&) in "/home/hannes/OpenFOAM/OpenFOAM-1.5-dev/lib/linux64GccDPOpt/libfiniteVolume.so"
#5 Foam::upwind<foam::vector<double> >::weights(Foam::GeometricField<foam::vector<doubl e>, Foam::fvPatchField, Foam::volMesh> const&) const in "/home/hannes/OpenFOAM/OpenFOAM-1.5-dev/lib/linux64GccDPOpt/libfiniteVolume.so"
#6 Foam::fv::gaussConvectionScheme<foam::vector<doubl e> >::fvmDiv(Foam::GeometricField<double,> const&, Foam::GeometricField<foam::vector<double>, Foam::fvPatchField, Foam::volMesh>&) const in "/home/hannes/OpenFOAM/OpenFOAM-1.5-dev/lib/linux64GccDPOpt/libfiniteVolume.so"
#7 Foam::tmp<foam::fvmatrix<foam::vector<double> > > Foam::fvm::div<foam::vector<double> >(Foam::GeometricField<double,> const&, Foam::GeometricField<foam::vector<double>, Foam::fvPatchField, Foam::volMesh>&, Foam::word const&) in "/home/hannes/OpenFOAM/OpenFOAM-1.5-dev/applications/bin/linux64GccDPOpt/interDy MFoam"
#8 Foam::tmp<foam::fvmatrix<foam::vector<double> > > Foam::fvm::div<foam::vector<double> >(Foam::GeometricField<double,> const&, Foam::GeometricField<foam::vector<double>, Foam::fvPatchField, Foam::volMesh>&) in "/home/hannes/OpenFOAM/OpenFOAM-1.5-dev/applications/bin/linux64GccDPOpt/interDy MFoam"
#9 main in "/home/hannes/OpenFOAM/OpenFOAM-1.5-dev/applications/bin/linux64GccDPOpt/interDy MFoam"
#10 __libc_start_main in "/lib/libc.so.6"
#11 Foam::regIOobject::writeObject(Foam::IOstream::str eamFormat, Foam::IOstream::versionNumber, Foam::IOstream::compressionType) const in "/home/hannes/OpenFOAM/OpenFOAM-1.5-dev/applications/bin/linux64GccDPOpt/interDy MFoam"
Floating point exception (core dumped)

The solver runs for a longer time when I change the div(rho*phi,U) scheme from upwind to limitedLinearV;. Then I even get output of time-directories and the fields look ok.

I will investigate further.

Best regards, Hannes

[hannes]

Little update: If I restart from the last timestep before the solver crash, the solver even runs beyond the simulation time of the crash. Looks like some variable is not properly initialized.

[eberberovic]

Hi Hannes.

Thanks for your replies. I have just seen this. What confuses me is that the function readDict() is the same also in 1.5.x, and it still works. I also don't see where it is called from.

But, what I have noticed is that the mesh changing engine is different. The 1.5-dev uses directTopoChange, while in 1.5.x it is polyTopoChange. This is the main and only difference between the files dynamicRefineFvMesh.C in the two versions. I will look around in directTopoChange to see if I can extract some additional information.

Best regards to you,
Edin.

[juliuslein]

Hello Hannes, hello Edin,

I have the same gamma issue with the exploding values using a derived version of rasInterFoam with dynamic Meshes. After the mesh deformation (by a pointDisplacement) the values go worse and worse and finally produce a floating point exception... Massive underrelaxation wasn't helping neither.
Actually I'm quite curious if the readDict() function could solve my problem as well. How and where do I call it?

Thanks for your answers,

Regards, Julius

[musahossein]

Gentlemen:

If I change the tank geometry to a square tank in the tutorial for the 2d tank sloshing in interDyMFoam,I get a multitude of error meesages. I am trying to model a 1 m X 1m X0.05m tank and the blockmeshDict file is as follows:

/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 1.5 |
| \\ / A nd | Web: http://www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object blockMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

convertToMeters 1;

vertices
(
( 0.5 -0.5 0.005) // 0
(-0.5 -0.5 0.005) // 1
(-0.5 0.5 0.005) // 2
( 0.5 0.5 0.005) // 3
( 0.5 0.5 -0.005) // 4
( 0.5 -0.5 -0.005) // 5
(-0.5 -0.5 -0.005) // 6
(-0.5 0.5 -0.005) // 7
);

blocks
(
hex (0 1 2 3 6 5 4 7) (10 10 1) simpleGrading (1 1 1)
);

patches
(
patch walls
(
(0 1 6 5)
(0 5 4 3)
(7 6 1 2)
(3 4 7 2)
)
empty front
(
(0 1 2 3)
)

empty back
(
(6 5 4 7)
)

);

// ************************************************** *********************** //

and the error I get is as follows:

musa@linux-ip9p:~/OpenFOAM/musa-1.5/run/tutorials/interDyMFoam/sloshingTank2Dtest> blockMesh
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 1.5 |
| \\ / A nd | Web: http://www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Exec : blockMesh
Date : Mar 19 2009
Time : 23:11:05
Host : linux-ip9p
PID : 4473
Case : /home/musa/OpenFOAM/musa-1.5/run/tutorials/interDyMFoam/sloshingTank2Dtest
nProcs : 1

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


Reading block mesh description dictionary

Creating block mesh

Creating blockCorners

There are no non-linear edges

Creating blocks

Creating patches

Creating block mesh topology
--> FOAM Warning :
From function cellModel::mag(const labelList&, const pointField&)
in file meshes/meshShapes/cellModel/cellModel.C at line 134
zero or negative pyramid volume: -0.00166667 for face 5

Default patch type set to empty


face 0 in patch 0 does not have neighbour cell face: 4(0 1 6 5)#0 Foam::error:rintStack(Foam::Ostream&) in "/home/musa/OpenFOAM/OpenFOAM-1.5/lib/linuxGccDPOpt/libOpenFOAM.so"
#1 Foam::error::abort() in "/home/musa/OpenFOAM/OpenFOAM-1.5/lib/linuxGccDPOpt/libOpenFOAM.so"
#2 Foam::Ostream& Foam:perator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) in "/home/musa/OpenFOAM/OpenFOAM-1.5/applications/bin/linuxGccDPOpt/blockMesh"
#3 Foam:olyMesh::facePatchFaceCells(Foam::List<Foam ::face> const&, Foam::List<Foam::List<int> > const&, Foam::List<Foam::List<Foam::face> > const&, int) const in "/home/musa/OpenFOAM/OpenFOAM-1.5/lib/linuxGccDPOpt/libOpenFOAM.so"
#4 Foam:olyMesh:olyMesh(Foam::IOobject const&, Foam::Field<Foam::Vector<double> > const&, Foam::List<Foam::cellShape> const&, Foam::List<Foam::List<Foam::face> > const&, Foam::List<Foam::word> const&, Foam::List<Foam::word> const&, Foam::word const&, Foam::word const&, Foam::List<Foam::word> const&, bool) in "/home/musa/OpenFOAM/OpenFOAM-1.5/lib/linuxGccDPOpt/libOpenFOAM.so"
#5 Foam::blockMesh::createTopology(Foam::IOdictionary &) in "/home/musa/OpenFOAM/OpenFOAM-1.5/applications/bin/linuxGccDPOpt/blockMesh"
#6 Foam::blockMesh::blockMesh(Foam::IOdictionary&) in "/home/musa/OpenFOAM/OpenFOAM-1.5/applications/bin/linuxGccDPOpt/blockMesh"
#7 main in "/home/musa/OpenFOAM/OpenFOAM-1.5/applications/bin/linuxGccDPOpt/blockMesh"
#8 __libc_start_main in "/lib/libc.so.6"
#9 __gxx_personality_v0 in "/home/musa/OpenFOAM/OpenFOAM-1.5/applications/bin/linuxGccDPOpt/blockMesh"


From function polyMesh::facePatchFaceCells(const faceList& patchFaces,const labelListList& pointCells,const faceListList& cellsFaceShapes,const label patchID)
in file meshes/polyMesh/polyMeshFromShapeMesh.C at line 125.

FOAM aborting

Aborted

Any suggestions?
Thanks, Musa

[WiWo]

Hi folks,

I am experiencing the very same problem using dynamicRefineFvMesh in OF-1.5-dev. Inserting readDict() in the constructor of dynamicRefineFvMesh.C (as Hannes suggested) improves the situation (crash due to 'floating point exception' is postponed to a later moment). I also see, that I can restart my solver at the last timestep and it will go on a little further.
Still, there must be something going the wrong way inside the refinement procedure. I was comparing the dynamicRefineFvMesh of OF-1.6 and OF-1.5-dev as the one in OF-1.6 obvieously works. There are two obvious differences - one (as mentioned earlier) is the substitution of polyTopoChange by directTopoChange. The other is in using PackedList instead of PackedBoolList. Can the failure be caused by a small e.g. indexing error in these lists?
Has anybody had a deeper look into the reason why the 1.5-dev version of dynamicRefineFvMesh does not work properly. Are there any solutions, hints, ideas so far?

I would apprechiate any help or advice as I'm desperately going to need this refinement and at the moment I feel a little lost searching through the code.

Cheers,
Wolfgang