[adriaanS]

Hi All

I am trying to compile a version of sonicFoam with automatic mesh refinement based on the gradient of the pressure field (stupid idea - I know, but it is a test, the mag(gradP)/max(mag(gradP)) gives worst scenario behaviour - refinement on boundaries, etc. I plan to ultimately use the solution error as the refinement criterion).

I started the process by looking at how dieselDyMFoam handles automatic mesh refinement and implemented a similar workflow in sonicFoam - I paid particular attention to the pressure equation, pEqn and the handling of the flux correction.

Obviously my attention was not sufficient.

The results between sonicFoam and mySonicDyMFoam with staticFvMesh and dynamicRefineFvMesh options in the dynamicMeshDict is identical - the flow solver works.

The run with mySonicDyMFoam and the dynamicRefineFvMesh option selected in the dynamicMeshDict fails with the following stack:

Time = 0.012
Selected 100 cells for refinement out of 5250.
Refined from 5250 to 5950 cells.
#0  Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam201/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#1  Foam::sigSegv::sigHandler(int) in "/opt/openfoam201/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#2  Uninterpreted: 
#3  Foam::dynamicRefineFvMesh::refine(Foam::List<int> const&) in "/opt/openfoam201/platforms/linuxGccDPOpt/lib/libdynamicFvMesh.so"
#4  Foam::dynamicRefineFvMesh::update() in "/opt/openfoam201/platforms/linuxGccDPOpt/lib/libdynamicFvMesh.so"
#5  
 in "/home/adriaan/OpenFOAM/adriaan-2.0.1/platforms/linuxGccDPOpt/bin/mySonicDyMFoam"
#6  __libc_start_main in "/lib/libc.so.6"
#7  
 in "/home/adriaan/OpenFOAM/adriaan-2.0.1/platforms/linuxGccDPOpt/bin/mySonicDyMFoam"
Segmentation fault

So obviously I am trying to access/write/append a vector outside of its defined scope - segmentation fault. The function which causes the segmentation fault is located in dynamicRefineFvMesh. Using the nemiver debugger I could track the problem to:

mySonicFoamDyM.C

//LINE NUMBERS 112 to 113 in the attached mySonicDyMFoam

            // Do any mesh changes
            bool meshChanged = mesh.update();

Step Into

dynamicRefineFvMesh.C

 
//LINE NUMBERS 330 to 356 in OF2.0.1

            // Recalculate new boundary faces.
            forAll(phi.boundaryField(), patchI)
            {
                fvsPatchScalarField& patchPhi = phi.boundaryField()[patchI];
                const fvsPatchScalarField& patchPhiU =
                    phiU.boundaryField()[patchI];

                label faceI = patchPhi.patch().start();

                forAll(patchPhi, i)
                {
                    label oldFaceI = faceMap[faceI];

                    if (oldFaceI == -1)
                    {
                        // Inflated/appended
                        patchPhi[i] = patchPhiU[i];
                    }
                    else if (reverseFaceMap[oldFaceI] != faceI)
                    {
                        // face-from-masterface
                        patchPhi[i] = patchPhiU[i];
                    }

                    faceI++;
                }
            }

The error is caught by UListI.H:

//LINE NUMBERS 97 to 113 in OF2.0.1

// Check index i is within valid range (0 ... size-1).
template<class T>
inline void Foam::UList<T>::checkIndex(const label i) const
{
    if (!size_)
    {
        FatalErrorIn("UList<T>::checkIndex(const label)")
            << "attempt to access element from zero sized list"
            << abort(FatalError);
    }
    else if (i<0 || i>=size_)
    {
        FatalErrorIn("UList<T>::checkIndex(const label)")
            << "index " << i << " out of range 0 ... " << size_-1
            << abort(FatalError);
    }
}

At first I though it had something to do with the fact that the first refinement (with normalised gradient of p) will occur on the inlet boundary patch. I changed the calculation for the gradP to absolute values and I set the minimum and maximum refinement criterion so that the first refinement will occur inside the flow-field. Same problem.

I am now at the end of my C++ tether (which wasn't very sturdy to begin with) and I was hoping that somebody out there might shed a different light on the problem. I am stumped. I have a strong suspicion that the problem has something to do with how the fluxes are corrected and particularly on the boundary patches. I haven't the faintest on where to start in correcting the problem.

I attached tar files with my code as well as a working case setup.

Your help will be much appreciated. Regards.

[adriaanS]

Right

So the problem reported by myself below has an easy resolution.

The dynamicRefineFvMesh.C file wants a 3D mesh with defined boundary conditions on each patch - no empties.

I am wandering into areas that do not concern me but I believe that the function that splits the cells produces the split in three directions. This causes extra cells in the mesh that do not "exist" for the solver. Hence the segmentation fault when the solver wants to index the additional cell values.

Anyway, I solved the reported problem by generating a new mesh with 5 cells in the "normal" direction.

My next error then occurred:

Time = 0.004
Selected 12 cells for refinement out of 26250.
Refined from 26250 to 26334 cells.


--> FOAM FATAL ERROR: 

    request for surfaceScalarField phi_0 from objectRegistry region0 failed
    available objects of type surfaceScalarField are

2
(
phi
weightingFactors
)


    From function objectRegistry::lookupObject<Type>(const word&) const
    in file /home/opencfd/OpenFOAM/OpenFOAM-2.0.1/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 131.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam201/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#1  Foam::error::abort() in "/opt/openfoam201/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#2  Foam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) in "/home/adriaan/OpenFOAM/adriaan-2.0.1/platforms/linuxGccDPOpt/bin/sonicDyMFoam"
#3  Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const& Foam::objectRegistry::lookupObject<Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> >(Foam::word const&) const in "/opt/openfoam201/platforms/linuxGccDPOpt/lib/libcompressibleTurbulenceModel.so"
#4  Foam::dynamicRefineFvMesh::refine(Foam::List<int> const&) in "/opt/openfoam201/platforms/linuxGccDPOpt/lib/libdynamicFvMesh.so"
#5  Foam::dynamicRefineFvMesh::update() in "/opt/openfoam201/platforms/linuxGccDPOpt/lib/libdynamicFvMesh.so"
#6  
 in "/home/adriaan/OpenFOAM/adriaan-2.0.1/platforms/linuxGccDPOpt/bin/sonicDyMFoam"
#7  __libc_start_main in "/lib/libc.so.6"
#8  
 in "/home/adriaan/OpenFOAM/adriaan-2.0.1/platforms/linuxGccDPOpt/bin/sonicDyMFoam"
Aborted

Hey, at least I was upgraded to a nice ABORT instead of a SEGMENTATION FAULT. I think - somewhere - in the multitude of files included into my little solver I am requesting a mass-flux with a variable name that does not exist.

After the previous problem this one should be a breeze.

But first - a beer, or two...

Regards.

[adriaanS]

Ok...update zwei

Everything works now - the request for phi_0 came from dynamicRefineFvMesh.C since it read from the dynamicMeshDict that I wanted to correct the flux...stupid...stupid...stupid. It seems that beer helps - I realized my mistake after having a few.

Anyway - lessons learnt:

1. dynamicMeshRefine won't work on any other mesh than a 3D mesh - this has to do with the way in which the cells are split, to fully understand the mesh splitting (and I don't!!!), read the source for dynamicRefineFvMesh.C as well as hex8somethingsomething I don't care. That was an interesting two hours. It is quite easy to visualize the methodology if you have Matlab available. I will let my understanding percolate for a few weeks.

2. If you have a 3D mesh make sure that all the boundary patches are defined with a boundary condition. Empty definitions on patches will not work. This actually relates to 1. above since a mesh with empty patches is not a 3D mesh. You can quickly identify this problem when OpenFOAM aborts with a message regarding accessing zero size elements.

3. Make sure that you know exactly what each parameter in dynamicMeshDict does.

4. Drink beer

I know that as I try to leave the harbor here I am going to be on the receiving end of a broadside but here goes:

Dear OpenCFD - don't you think that it would be nice to just include a few checks in dynamicRefineFvMesh.C to ensure that everything mesh related is in order. I did it for my own code but I really think that it will save a lot of naive, idealistic, enthusiastic users a lot of time. I am also quite wary of using the bug report system since I have seen some of the replies to bug reports and change requests. I get roasted enough at work. {Cringe}

Lastly - a little picture. Mesh at 0.6 seconds into the simulation (I didn't bother going further since I will be changing the whole solver now that the prototype is finished)



Cheers everyone. I had a smashing time writing to myself on the internet. I hope my feeble attempt might help some poor soul somewhere.

[kmooney]

I'm surpised that 2d meshes are still unsupported. Lots of people would benefit from it.

[adriaanS]

Last post to this thread

My understanding has percolated and I think I can now make some sweeping and philosophical statements regarding my previous posts:

1. OpenFOAM uses octree decomposition to refine the cells. This is beautiful since it means that the data structure (containing cell data - face areas, cell center coordinates, volumes, etc.) is also properly decomposed. This little comment block is to small to express exactly how impressive this method of decomposition is. It also explains the ease with which OpenFOAM {un}-decomposes cells - the informational structure is a tree so you always know exactly where to go - you simply follow the branches of the octree up and down. I also suspect that whoever wrote this particular piece of code was a) a genius, b) also having a lot of beer . I simply cannot get over how impressed I am with this code. It just shows how innovative someone can be at the intersection of CFD and applied mathematics.

2. With regards to the last reply to my post - since OpenFOAM had been designed to generate and manipulate fields for CFD applications it would be detract from the elegance of the code implementation to work in 2D. 2D is simply a special case of the tensor fields that OpenFOAM was designed to handle. It is up to us, the users to a) understand how OpenFOAM manages to manipulate these fields, b) ...and to work in that paradigm. It might seem easier, at first, to try and translate OpenFOAM to the "classical" gradient based way of working but in the process we are losing the power and flexibility that OpenFOAM offers i.t.o of vector based mathematics and object orientation.

Just last week I had three students code an implicit solution for the Riemann problem in OpenFOAM with 100 cell x 1 cells x 1 cells. Upon completion I had them re-mesh the domain but now with cells in the y and z-directions and plot the results. This is the power of OpenFOAM - absolute generalization which saves a LOT of time. Remember the old days when going from a 1D FVM to a 3D FVM was a task that required hair on your teeth and absolutely no social life.

[canfield]

Thank you for posting you difficulties and your solutions. I managed to make the same mistake (assume that 3d refinement would work on a 2d mesh) and for the life of me couldn't figure out what was wrong. Just stumbled across this thread and all is clear now (i hope).

[adriaanS]

My pleasure, that is what this forum should be for. Good luck.

[Ed R]

Hi,

I'm currently working on developing a numerical wave tank (NWT) in OpenFOAM using the additional waves2Foam libraries to generate waves using a wave inlet boundary. I was hoping to use the automatic mesh refinement to follow the free surface in my NWT but I'm really struggling to get it to work.

my initial attempt gave this error:
The terminal gives the following:

/opt/openfoam211/bin/tools/RunFunctions: line 37: 3280 Segmentation fault (core dumped) $APP_RUN $* > log.$APP_NAME 2>&1

The log file give this (after the usual preliminaries)

Starting time loop

Interface Courant Number mean: 6.86629e-05 max: 0.0102554
Courant Number mean: 0.00296173 max: 0.010832
deltaT = 0.00116279
Time = 0.00116279

Selected 3740 cells for refinement out of 75000.
Refined from 75000 to 101180 cells.
#0 Foam::error:rintStack(Foam::Ostream&) in "/opt/openfoam211/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigSegv::sigHandler(int) in "/opt/openfoam211/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#2 Uninterpreted:
#3 Foam::dynamicRefineFvMesh::refine(Foam::List<int> const&) in "/opt/openfoam211/platforms/linuxGccDPOpt/lib/libdynamicFvMesh.so"
#4 Foam::dynamicRefineFvMesh::update() in "/opt/openfoam211/platforms/linuxGccDPOpt/lib/libdynamicFvMesh.so"
#5
in "/home/eransley/OpenFOAM/eransley-2.1.1/platforms/linuxGccDPOpt/bin/waveDyMFoam"
#6 __libc_start_main in "/lib/i386-linux-gnu/libc.so.6"
#7
in "/home/eransley/OpenFOAM/eransley-2.1.1/platforms/linuxGccDPOpt/bin/waveDyMFoam"

Since I have started from scratch using the damBreakWithObstacle tutorial as a basis, but as soon as I change one wall to an inlet boundary with a fixed velocity and alter the associated boundarys in 0/alpha1, 0/p_rgh, 0/U I run into more problems.

Has anyone managed to use the interDyMFoam solver with an inlet boundary? Any help would be much appreciated.

Ed

[adriaanS]

Ed

Please post your case and I will take a look (constant directory should be sufficient). As a first shot I can unequivocally state that I am 99% sure the problem is with the setup. Your solver and the AMR method itself is largely problem-free.

The output stack gives you a good idea of what happened here.

STEP 0: Everything was going well and you were getting increasingly excited thinking to yourself that you can't believe that it actually works.

Interface Courant Number mean: 6.86629e-05 max: 0.0102554
Courant Number mean: 0.00296173 max: 0.010832
deltaT = 0.00116279
Time = 0.00116279

STEP 1: Your code entered the refinement loop given that the refinement criteria was satisfied in a certain group of cells.

Selected 3740 cells for refinement out of 75000.

STEP 2: The cells were successfully refined - the code tells you that when it displayed the new cell count

Refined from 75000 to 101180 cells.

STEP 3: A segmentation fault occurred.

#0 Foam::error:rintStack(Foam::Ostream&) in "/opt/openfoam211/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigSegv::sigHandler(int) in "/opt/openfoam211/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"

Segmentation faults have a number of underlying causes and is caused when some variable had grown outside of its allocated size. The software then tries to access memory that it is not allowed into resulting in a segmentation fault or a stack overflow error.

How could this happen? What grew past its allocated size? The resolution of these questions holds the answer you are seeking (hahahaha, I just had to add that last bit, excuse me). I won't answer these just yet, you should have a think about it after reading my previous posts.

Regards

[Ed R]

Hi Adriaan, thank you for your quick reply and offer of help. Your steps are exactly how I was feeling immediately after hitting the go button. I'm struggling to work out why its gone wrong as the case has been run multiple times in 2D before without the dynamic mesh and all I've changed are the sides to walls and put 10 cells wide. Here are the files from my constant directory:

dynamicMeshDict:

dynamicFvMesh dynamicRefineFvMesh;

dynamicRefineFvMeshCoeffs
{
// How often to refine
refineInterval 1;
// Field to be refinement on
field alpha1;
// Refine field inbetween lower..upper
lowerRefineLevel 0.001;
upperRefineLevel 0.999;
// If value < unrefineLevel unrefine
unrefineLevel 10;
// Have slower than 2:1 refinement
nBufferLayers 1;
// Refine cells only up to maxRefinement levels
maxRefinement 2;
// Stop refinement if maxCells reached
maxCells 200000;
// Flux field and corresponding velocity field. Fluxes on changed
// faces get recalculated by interpolating the velocity.
// on surfaceScalarFields that do not need to be reinterpolated.
correctFluxes
(
(phi Urel)
(phiAbs U)
(phiAbs_0 U_0)
(nHatf none)
(rho*phi none)
(ghf none)
);
// Write the refinement level as a volScalarField
dumpLevel true;
}


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

blockMeshDict:

*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object blockMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

convertToMeters 1;

vertices
(
( 0 -1.0 0 )
( 20 -1.0 0 )
( 0 1.0 0 )
( 20 1.0 0 )

( 0 -1.0 0.5 )
( 20 -1.0 0.5 )
( 0 1.0 0.5 )
( 20 1.0 0.5 )
);

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

edges
(
);

patches
(
wall inlet
(
(0 4 6 2)
)
wall bottom
(
(0 1 5 4)
)
wall outlet
(
(1 5 7 3)
)

patch atmosphere
(
(2 3 7 6)
)

wall frontBack
(
(0 1 3 2)
(4 5 7 6)
)
);

mergePatchPairs
(
);

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

waveProperties (if you are not familiar with waves2Foam this holds the information for the inlet boundary)

FoamFile
{
version 2.0;
format ascii;
class dictionary;
object environmentalProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

timeShift 0.0;

seaLevel 0.00;

// A list of the relaxation zones in the simulation. The parameters are given
// in <name>Coeffs below.
relaxationNames ();

initializationName inlet;

pName p_rgh;

inletCoeffs
{
waveType solitaryFirst;

// Ramp time of 2 s
//Tsoft 2;

height 0.4;

depth 1.000000;

direction (1.0 0.0 0.0);

x0 (10.0 0.0 0.0);

};

outletCoeffs
{
waveType potentialCurrent;
U (0 0 0);
Tsoft 2;

};



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

turbulenceProperties:

simulationType laminar;

environmentalProperties:

g g [0 1 -2 0 0 0 0] (0 -9.81 0);

transportProperties:

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

phase1
{
transportModel Newtonian;
nu nu [0 2 -1 0 0 0 0] 1e-06;
rho rho [1 -3 0 0 0 0 0] 1000;
CrossPowerLawCoeffs
{
nu0 nu0 [0 2 -1 0 0 0 0] 1e-06;
nuInf nuInf [0 2 -1 0 0 0 0] 1e-06;
m m [0 0 1 0 0 0 0] 1;
n n [0 0 0 0 0 0 0] 0;
}
BirdCarreauCoeffs
{
nu0 nu0 [0 2 -1 0 0 0 0] 0.0142515;
nuInf nuInf [0 2 -1 0 0 0 0] 1e-06;
k k [0 0 1 0 0 0 0] 99.6;
n n [0 0 0 0 0 0 0] 0.1003;
}
}

phase2
{
transportModel Newtonian;
nu nu [0 2 -1 0 0 0 0] 1.48e-05;
rho rho [1 -3 0 0 0 0 0] 1;
CrossPowerLawCoeffs
{
nu0 nu0 [0 2 -1 0 0 0 0] 1e-06;
nuInf nuInf [0 2 -1 0 0 0 0] 1e-06;
m m [0 0 1 0 0 0 0] 1;
n n [0 0 0 0 0 0 0] 0;
}
BirdCarreauCoeffs
{
nu0 nu0 [0 2 -1 0 0 0 0] 0.0142515;
nuInf nuInf [0 2 -1 0 0 0 0] 1e-06;
k k [0 0 1 0 0 0 0] 99.6;
n n [0 0 0 0 0 0 0] 0.1003;
}
}

sigma sigma [1 0 -2 0 0 0 0] 0.00;

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

Thanks again,

Ed

[Ed R]

Further to my previous post. The exact same case runs with no problems when using the waveFoam solver (interFoam coupled with waves2Foam libraries) instead of waveDyMFoam (interDyMFoam coupled with waves2Foam).

[adriaanS]

Ed

Please post your boundary file as well. Everything seems fine so far...

[Ed R]

Adriaan, thanks again for your help. After you previous message I checked the boundary file and it still had a remnant 'empty' boundary type in it from my 2D work. Having changed this I now have a new error message.

Terminal says:
/opt/openfoam211/bin/tools/RunFunctions: line 37: 3182 Aborted (core dumped) $APP_RUN $* > log.$APP_NAME 2>&1

log says:

tarting time loop

Interface Courant Number mean: 6.86629e-05 max: 0.0102554
Courant Number mean: 0.00296173 max: 0.010832
deltaT = 0.00116279
Time = 0.00116279

Selected 3740 cells for refinement out of 75000.
Refined from 75000 to 101180 cells.
Selected 0 split points out of a possible 3740.
Execution time for mesh.update() = 2 s
time step continuity errors : sum local = 0.000259311, global = -5.74747e-13, cumulative = -2.65254e-09


--> FOAM FATAL ERROR:
field does not correspond to level 0 sizes: field = 101180 level = 75000

From function void GAMGAgglomeration::restrictField(Field<Type>& cf, const Field<Type>& ff, const label fineLevelIndex) const
in file lnInclude/GAMGAgglomerationTemplates.C at line 47.

FOAM aborting

#0 Foam::error:rintStack(Foam::Ostream&) in "/opt/openfoam211/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#1 Foam::error::abort() in "/opt/openfoam211/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#2 void Foam::GAMGAgglomeration::restrictField<double>(Foa m::Field<double>&, Foam::Field<double> const&, int) const in "/opt/openfoam211/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#3 Foam::GAMGSolver::agglomerateMatrix(int) in "/opt/openfoam211/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#4 Foam::GAMGSolver::GAMGSolver(Foam::word const&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::dictionary const&) in "/opt/openfoam211/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#5 Foam::lduMatrix::solver::addsymMatrixConstructorTo Table<Foam::GAMGSolver>::New(Foam::word const&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::dictionary const&) in "/opt/openfoam211/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#6 Foam::lduMatrix::solver::New(Foam::word const&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::dictionary const&) in "/opt/openfoam211/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#7 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/openfoam211/platforms/linuxGccDPOpt/lib/libfiniteVolume.so"
#8 Foam::fvMatrix<double>::solve() in "/home/eransley/OpenFOAM/eransley-2.1.1/platforms/linuxGccDPOpt/bin/waveDyMFoam"
#9
in "/home/eransley/OpenFOAM/eransley-2.1.1/platforms/linuxGccDPOpt/bin/waveDyMFoam"
#10 __libc_start_main in "/lib/i386-linux-gnu/libc.so.6"
#11
in "/home/eransley/OpenFOAM/eransley-2.1.1/platforms/linuxGccDPOpt/bin/waveDyMFoam"

Thanks again,
Ed

[Ed R]

Having read this post I now have managed to get something to run. I'm yet to try my original, but progress.

http://www.cfd-online.com/Forums/ope...erdymfoam.html

you must disable the cacheAgglomeration option, i.e. set it to "cacheAgglomeration off;" in fvSolution. (I used false instead of off). Does anyone know what this does?

Ed

[Ed R]

Hello,

I have managed to run my initial case using mesh refinement and it all works well. However, in order to keep the mesh course in regions far from the free surface I believe you must specify a course mesh in the blockMeshDict. then refinement occurs around the free surface at the first timestep, but this smears the freesurface badly. Ideally I'd like to specify a very fine mesh in the blockMeshDict and the dynamic mesh automatically unrefine the mesh in areas away from the free surface. Is there any way to set the refinementLevel to the maxRefinement at time 0?

Thanks,

Ed