Mahdi,

Clearly, you have a messed up Mesquite installation. Ensure that mesquite is installed properly, and that the $MESQUITE_DIR environment variable is set before compiling the mesquiteMotionSolver library.

Dear Sandeep

Many Thanks for your reply.
Exactly I think the same. I have installed the mesquite according to its installation guide correctly. I think I have installed it correctly. But I have doubt that I have defined the environment variable correctly or not.
I just added

to my .bashrc file and running the ldconfing. then when i run env , it shows the MESQUITE_DIR as environment variable and LD_LIBRARY_PATH, I am working on openfoam 2.1.x in ubuntu 10.04. but still when im compiling the dynamictopochanfe i have the errors.

Best
Mahdi

Dear Philippose,

have you found a workaround for your problem?
I also ran into this error regarding epsilonWallFunction.
In my case, this occured if the mesh between two parallel patches representing a wall was too coarse.
Maybe a refinement of your initial mesh could help you?

Thanks to Sandeep for his excellent library!

Regards,
Georg

Georg and Philippose,

Could you try with the Port-2.1.x branch using OpenFOAM-2.1.x? I'd like to know if you have the same result.

Thanks

Hello Sandeep,

unfortunately I can not use OF-2.1.x so far.
Still some work to finish before I can give it a try!

But thank you very much for your response.
As soon as possible, I will come back to your request.

Regards,
Georg

Dear colleagues,

I'd like to ask you if your trials with adaptive mesh refinement (AMR) on tetrahedral meshes were successful. If so, could you please describe a bit what changes did you make in OF-1.6-ext code? I would be very grateful for some hints.

Best regards,
Aleksey.

P.S. Looking to this thread I realized that this task is not trivial. As far as I understand standard OpenFOAM techniques allow to perform AMR of hexahedral meshes. The dynamicTopoFvMesh class should allow to do AMR on tetrahedral meshes. However, if the processes of bisection/collapse appear to often the mesh smoothing is needed. Did I understand right? If so, do I need to run mesquite after refinement? What was you successful algorithm?

Dear Sandeep:

I am using OpenFoam 1.6-ext with your dynamicTopoFvMesh to simulate sedimentation of spheres. Thanks a lot for your very good job.

However, I have a problem with the ultimate version of: updateMesh,
in particular with: fvMesh::updateMesh(mpm);

Have you any idea?

Thank you in advance,

Reordering time: 0.180952 s
toto1:
toto11:
toto12:
[workstation:12355] *** Process received signal ***
[workstation:12355] Signal: Segmentation fault (11)
[workstation:12355] Signal code: (-6)
[workstation:12355] Failing at address: 0x3e800003043
[workstation:12355] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x324f0) [0x7f8fdf4c64f0]
[workstation:12355] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f8fdf4c6475]
[workstation:12355] [ 2] /lib/x86_64-linux-gnu/libc.so.6(+0x324f0) [0x7f8fdf4c64f0]
[workstation:12355] [ 3] /home/olivier/OpenFOAM/olivier-1.6-ext/lib/linux64Gcc47DPOpt/libdynamicTopoFvMesh.so(_ZNK4Foam15topoPatchMapper 14calcAddressingEv+0x567) [0x7f8fd1747247]
[workstation:12355] [ 4] /home/olivier/OpenFOAM/olivier-1.6-ext/lib/linux64Gcc47DPOpt/libdynamicTopoFvMesh.so(_ZNK4Foam15topoPatchMapper 10addressingEv+0x82) [0x7f8fd1748002]
[workstation:12355] [ 5] nonNewtonianSixDOFFoam(_ZN4Foam5FieldIdE7autoMapER KNS_11FieldMapperE+0x89) [0x465c89]
[workstation:12355] [ 6] /home/olivier/OpenFOAM/olivier-1.6-ext/lib/linux64Gcc47DPOpt/libdynamicTopoFvMesh.so(_ZN4Foam24conservativeMapV olFieldsIdEEvRKNS_10topoMapperE+0x1bb) [0x7f8fd15f408b]
[workstation:12355] [ 7] /home/olivier/OpenFOAM/olivier-1.6-ext/lib/linux64Gcc47DPOpt/libdynamicTopoFvMesh.so(_ZNK4Foam17dynamicTopoFvMe sh9mapFieldsERKNS_11mapPolyMeshE+0x56) [0x7f8fd15db196]
[workstation:12355] [ 8] /home/olivier/OpenFOAM/OpenFOAM-1.6-ext/lib/linux64Gcc47DPOpt/libfiniteVolume.so(_ZN4Foam6fvMesh10updateMeshERKN S_11mapPolyMeshE+0x44) [0x7f8fe26b8344]
[workstation:12355] [ 9] /home/olivier/OpenFOAM/olivier-1.6-ext/lib/linux64Gcc47DPOpt/libdynamicTopoFvMesh.so(_ZN4Foam17dynamicTopoFvMes h10updateMeshERKNS_11mapPolyMeshE+0x86) [0x7f8fd15ccc46]
[workstation:12355] [10] /home/olivier/OpenFOAM/olivier-1.6-ext/lib/linux64Gcc47DPOpt/libdynamicTopoFvMesh.so(_ZN4Foam17dynamicTopoFvMes h9resetMeshEv+0x1491) [0x7f8fd15de5e1]
[workstation:12355] [11] /home/olivier/OpenFOAM/olivier-1.6-ext/lib/linux64Gcc47DPOpt/libdynamicTopoFvMesh.so(_ZN4Foam17dynamicTopoFvMes h6updateEv+0x206) [0x7f8fd15e2416]
[workstation:12355] [12] nonNewtonianSixDOFFoam() [0x425858]
[workstation:12355] [13] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f8fdf4b2ead]
[workstation:12355] [14] nonNewtonianSixDOFFoam() [0x42a67d]
[workstation:12355] *** End of error message ***

-----------------------------------------------------------------
// Update mesh corresponding to the given map
void dynamicTopoFvMesh::updateMesh(const mapPolyMesh& mpm)
{
if (coupledModification_)
{
// This bit gets called only during the load-balancing
// stage, since the fvMesh::updateMesh is a bit different
fvMesh::updateMesh(mpm);
return;
}

// Delete oldPoints in polyMesh
polyMesh::resetMotion();
Info<< " toto12: "
<< endl;
// Update fvMesh and polyMesh, and map all fields
fvMesh::updateMesh(mpm);
Info<< " toto13: "
<< endl;
}

Olivier,

It looks like you're running into the same issue that Philippose encountered. Take a look at some of his earlier posts on this thread. You could temporarily switch off the conservative mapping bits in mapFields and see how that fares.

Aleksey,

The dynamicTopoFvMesh class doesn't do AMR in the classical stencil-based approach where derefinement recovers the original mesh. I've played around with implementing that, but it's nowhere near complete at the moment.

Smoothing is generally recommended with the current approach because recursive edge bisection/collapse typically tends to yield poorer quality meshes (also a reason why the edge-swapping algorithm exists). From what I've seen so far, this approach is usually sufficient for most cases.

Dear Sandeep,

thank you very much for your reply and your hints!

In fact, I don't need to obtain original mesh after derefinement. If the characteristic mesh size will behave the way I expect I will be just happy.

I tried to do AMR on purely hexahedral meshes using dynamicRefineFvMesh. However the results are not very impressing - I get some unphysical oscillations of wall shear stress on walls. So definitely I will try to use your class with mesh smoothing on tetrahedral meshes.

Best regards,
Aleksey.

Dear Sandeep:

Thank you very much for you help, I removed:
conservativeMapVolFields<scalar>(fieldMapper);
conservativeMapVolFields<vector>(fieldMapper);

and

conservativeMapSurfaceFields<scalar>(fieldMapper);
conservativeMapSurfaceFields<vector>(fieldMapper);

Now the program is running but I do not understand why, please me, can you explain me what I do when I remove these lines?

Thank you in advance,

Olivier

Olivier,

You shouldn't remove them completely - just replace them with the non-conservative counterparts:

MapGeometricFields<scalar,fvPatchField,topoMapper, volMesh>(fieldMapper);
MapGeometricFields<vector,fvPatchField,topoMapper, volMesh>(fieldMapper);

and

MapGeometricFields<scalar,fvsPatchField,topoMapper ,surfaceMesh>(fieldMapper);
MapGeometricFields<vector,fvsPatchField,topoMapper ,surfaceMesh>(fieldMapper);

It appears to be an addressing issue in the conservative mapper that needs to be looked into, but I don't have any time at the moment.

The difference between mappers is that flow variables (like momentum, pressure, etc) may not be fully conserved while remapping with the modified lines.

Hello there,

I see that the topic of AMR using Sandeep's library has come up again. I am sorry for having fallen off the radar over the last few months. Lot of other matters have kept me from focusing on the Tetrahedral AMR issue.

@Olivier: I dont think Sandeep meant that you should be "removing" the mesh mapping functions. You need to remove the "conservative" mesh mapping routines and replace them with the normal "non-conservative" equivalents. If you completely remove the mapping, your fields will not get mapped when performing topological changes to the mesh.

During the time when I was (I still am, just that I havent had the time to look into it) trying to implement AMR for tetrahedral meshes using this library, I made some modifications to the code.

Here are some observations / results from my trials:

1. My goal was to use a field based Mesh refinement, with the length-scale created from the residual error (See: http://powerlab.fsb.hr/ped/kturbo/Op...emEstimate.pdf .... and the code for "simpleFoamResidual" in the OpenFOAM-ext distribs).

2. In order to achieve the field based length-scale, I modified the stock version of "simpleFoam" to one which can handle dynamic meshes, and calculates the error residual at each iteration and dumps it to a file.

3. I modified Sandeep's library to incorporate this field based length-scale into the mesh length-scale calculation routines. In addition, I also had to remove the "conservative" mesh mapping routines, and replace them with the "non-conservative" equivalents due to the same error seen by Olivier...... As far as I have understood, when performing a steady-state calculation, you do not need the mapping to be strictly conservative, because the solution can stabilise / converge in the next few steps after the mesh modifications take place.

4. The modified code can be found at: https://github.com/philippose/dynamicTopoFvMesh

5. The results of the tests have been..... mixed. I got some amount of success, but its not ready for general use yet..... here are some thoughts:

----* The actual refinement and coarsening implemented by the library seems to work fine.... In my case, it is not important to get back to the original mesh when coarsening.

----* The problem comes at the field-based length-scale part of the code. Between two "legal" remeshing steps (as specified in the dict file), the library also performs remeshing steps when the quality of the mesh falls below a threshold.
Immediately after a mesh modification, for the next few steps, the mesh quality may drop below the threshold causing addition remeshing steps in several successive steps. However, immediately after a remeshing step, the error residuals are also very high (due to the non-conservative mapping).... This causes the length-scale field to go haywire, which then gets picked up by the subsequent remeshing steps, causing the simulation to spiral down and crash.

----* The above problem can be avoided only by "freezing" the length-scale field for some number of steps immediately after a remeshing step. However, I am not sure how to do this, because a mesh modification step changes the number of points in the mesh. If the previous length-scale field (with the old number of points) is frozen and re-applied during the remeshing steps triggered by mesh quality, the system will crash because the number of points in the frozen length-scale field will not be the same as the number of points in the current mesh......

Any ideas how to tackle this issue?

----* Other than that, the system seems to be working :-)!

----* I have not yet put up the code for my modified "simpleFoam" solver anywhere, but I can put it up on to my Github website tomorrow.


Hope this helps...... I would be grateful if someone would be interested in helping out with this :-)!

Have a great day ahead!

Philippose

Ahhh :-)! Sandeep.... you beat me to it in giving Olivier an answer :-)! I had a sneaky feeling that in the time it took me to write my relatively "long" post, you would be busy typing away a reply :-)!

Philippose

Dear Philippose and Sandeep:

Thank you very much for your help and quick comments, I will try your changes tomorrow and I will let you know...

Regards,

Olivier

Dear Philippose and Sandeep

@Sandeep: I tried to replace "conservative" mesh mapping routines by the normal "non-conservative" equivalents but I obtained the same error.

@Philippose: I installed your modified dynamicTopoMesh and up to now I have no problem, thank you for your help and the paper.

Regards,

Olivier

Hello,

Just for information, I have uploaded the modified version of simpleFoam which I use for the Automated Mesh Refinement experiments.

The solver creates two additional fields.... the error residual, and the pressure gradient for each time-step. One of these fields can then be used for the field based mesh refinement option in the modified version of Sandeep's library.

The source can be found at: https://github.com/philippose/simpleFoamAMR

Have a great day ahead!

Philippose

Sandeep,

as planned two months ago, I now switched to OF-2.2.x and your corresponding branch.
So far, the error of crash while mapping turbulent fields does not occur any more.
Thank you for this hint.

Best regards,
Georg

Hello Philoppose, Sandeep, et. al.

I'm trying to solve a sloshing problem. I'm using the solver interDyMFoam, from 1.6-ext, and the Sandeep's library to adapt the mesh around the interface.

The first issue I faced was to setup an initial case, i. e. a case with a correct mesh. The base mesh was generated using gmsh and the alpha1 field was set with funkySetFields. Then I used a modified moveDynamicMesh, which includes the field alpha1, to improve the mesh following the options in dynamicMeshDict. You can find this file attached. The resulting mesh was used for the interDyMFoam runs.

I could not finish any run after this point. For some reason, a wrong setup problably, the alpha1 field map onto the new mesh it is wrong. Attached you can find two sets of snapshots with the alpha1 field before and after the change. The first one from time 0.009 to 0.010, and the second one from 0.019 to 0.020. In the pictures you can see cells which initially had a value of 1 that after the remeshing has values <1.

I would appreciate any thought or idea to solve this problem.

Regards

Pablo

Pablo,

Remapping of discontinuous fields is still a little dicey at the moment, so I wouldn't try it at the moment with VOF methods, particularly since interFoam is not very reliable on non-orthogonal meshes. But the part where alpha goes below 1.0 in an area that is clearly all fluid is concerning, which could mean a bug in the field mapping. Have you tried writing out the alpha field after mesh.update() (but before the PISO loop) and checking if the field is mapped correctly then?

Sandeep,

thank you for your quick reply. I modified the standard interDyMFoam from OF1.6-ext adding a field called alpha1Clone in the createFields.H and the following lines in the main file.

You can download the pictures here. The fields are not exactly the same. You will see the difference at times 0.019 and 0.020.

Your comments let me a bit concerned. A few questions arise
1) Is the remapping step of discontinuos fields an issue due to interFoam or the field itself?
2) May I help you to improve the mapping of discontinuos fields?
3) Due to the geometries I have to discretize I can not use orthogonal meshes. Do you know a way to improve interFoam?

Regards

Pablo

Pablo,

1. The issue with remapping is not due to interFoam, but the field itself - discontinuous fields need to be handled carefully. Improper remapping of VOF fields can lead to mass gain / loss.
2. You can surely help, but it's not altogether trivial - you'll need to locally reconstruct the interface in the area prior to re-meshing, map geometrically with some intersection calculations, and re-assign to the new re-meshed cells. You can alternatively scale up/down in some intelligent way as a form of local repair.
3. I'm probably not the best person to consult on VOF methods, but I do believe that a PLIC approach would go a long way in alleviating the non-orthogonal issues (I think).

SixDOFFoam in paralell
 

Dear Sandeep:

I am using OpenFoam 1.6-ext with your dynamicTopoFvMesh, using the solver sixDOFFoam. Thanks you very much for all that great job!

I run many cases of sedimentation of spheres, without problems, and get very good solutions, with one processor.
But i have a problem with more processors (2,3,4,5...), running the case in paralell. The solution have a good convergence at the begining, but the solution start to oscillate after a remeshing, and break the simulation.

I tryed many modifications of my case, for many days, but i can't find the problem.
I actually think that maybe it's a problem of the code. Do you use sixDOFFoam in paralell today?
can you explain me how i have to use paralell in sixDOFFoam?

I need to run simulation in paralell, because today with one processor the simulation takes too much time for the basic cases, and i need to simulate more complex cases right now.

Thank you in advance,

Problem maybe with conservative mapping?. OF1.6-ext crashing
 

Hi,

I am having an issue that it seems related to a problem previously reported by olivier_au_chili.

Basically, after updating my system to opensuse 12.2 many apps stop working, included OF-1.6-ext. I am using gcc 4.7.1, I updated OF-1.6-ext and dynamicTopoFvMesh to the latest release and I am using mesquite 2.1.2.

So far I haven't run an actual simulation, I am just using moveDynamicMesh. My problem is that OF is crashing after running a few iterations, this is a partial output using debug 1:


Edge Swapping complete.
Topo modifier time: 0.016324 s
Bisections :: Total: 2, Surface: 0
Collapses :: Total: 0, Surface: 0
Swaps :: Total: 8, Surface: 1
*** Mapping is being skipped ***
Mapping time: 2e-05 s

=================
Mesh reOrdering
=================
Mesh Info [n]:
Points: 1838
Edges: 11154
Faces: 17911
Cells: 8594
Internal Edges: 8985
Internal Faces: 16465
=================
Mesh Info [n+1]:
Points: 1840
Edges: 11168
Faces: 17935
Cells: 8606
Internal Edges: 8999
Internal Faces: 16489
=================
Checking index ranges...Done.
Checking face-cell connectivity...Done.
Checking for unused points...Done.
Checking edge-face connectivity...Done.
Checking point-edge connectivity...Done.
Checking edge-points connectivity...Done.
Checking cell-point connectivity...Done.
ReOrdering points...Done.
ReOrdering cells...Done.
ReOrdering faces...Done.
ReOrdering edges...Done.
Reordering time: 0.051737 s
void dynamicTopoFvMesh::mapFields(const mapPolyMesh&): Mapping fv fields.

Segmentation fault



I managed to track down the problem to:

MapGeometricFields<scalar,fvsPatchField,topoMapper ,surfaceMesh>
(fieldMapper);


If I comment out this line moveDynamicMesh works fine.
Any idea what could be the problem?

I dont fell quite comfortable commenting this line as if I understood well, it is related to conservative mapping.


Thanks for your help

jg

Can you post a simple test-case that fails? I'd like to take a look.

Hi,

Well basically all of them. But you can try circCylinder3d, on my system it crash when time = 7.

Let me add that to compile I am using the option -fpermissive with gcc-4.7.1.


jg

Could you try with the Port-2.2.x branch of the github repository? My 1.6-ext installation is kind of a mess at the moment. I ran the circCylinder3d case with OpenFOAM-2.2.x and it seemed to work okay.

Hi,

Well that is the next point in my to do list. I was looking to solve first the problem with 1.6-ext version as I am doing some developing in there.

In anycase, with version 2.2.X I am having problems as well. Basically everything started after I upgraded my system to opensuse 12.2. I am using gcc 4.7.1, mesquite 2.2.0 and following your installation instructions. Everything compiles fine, but when I use moveDynamicsMesh with circCylinder3d tut (or any of my previous cases), I am getting this error


--> FOAM FATAL IO ERROR:
Unknown patchField type angularOscillatingDisplacement for patch type wall

Valid patchField types are :

18
(
calculated
codedFixedValue
cyclic
cyclicAMI
cyclicSlip
empty
fixedNormalSlip
fixedValue
nonuniformTransformCyclic
processor
processorCyclic
slip
symmetryPlane
timeVaryingUniformFixedValue
uniformFixedValue
value
wedge
zeroGradient
)

file: /home/joegi/OpenFOAM/joegi-2.2.x/my_runs/circCylinder3d/constant/dynamicMeshDict.mesquiteOptions.fixedValuePatches. topWall from line 93 to line 101.

From function PointPatchField<Type>::New(const pointPatch&, const Field<Type>&, const dictionary&)
in file /home/joegi/OpenFOAM/OpenFOAM-2.2.x/src/OpenFOAM/lnInclude/pointPatchFieldNew.C at line 144.

FOAM exiting



Any clue?
Btw, All libraries exist.

This is telling me that moveDynamicMesh is not finding the motion libraries. Those libraries are compiled with dynamicTopoFvMesh? are they different from the ones in OF22x?. Because if I add libs ("libfvMotionSolvers.so"); to controlDict the error disappear, but basically nothing happens.

In anycase let me troubleshoot this issue, maybe there is something odd on my installation.


jg

Hi Sandeep,

Ok I erased my previous OF2 installation, installed a few updates and recompiled everything again and now it seems that it is working. The only observation is that I need to add

libs ("libfvMotionSolvers.so")

To the controlDict dictionary.

Btw, I am still interested in fixing the problem with OF16-ext.


Regards,

jg

I'll take a look at my 1.6-ext installation and see if I can figure out what's wrong. Will keep you posted.

@ joegi.geo
Hi Jeogi.geo:

Have you a problem with dynamicTopoFvMesh (last version) when you run it in mpi?

I found that there is a problem in dynamicTopoFvMeshCoupled.C initFieldTransfers
>

You can see my previous post:
www.cfd-online.com/Forums/openfoam-solving/111926-questions-dynamictopofvmesh-3.html

Regards,

Olivier

Hello folks - I recently pushed a few bug-fixes to the github repository. Could you check now and tell me if the issue is now rectified?

Thanks

Dear Sandeep

ok very good news, thank you very much, I followed your work since many days, I test it this weekend,


Regards,

Olivier

Dear Sandeep:

I carried out a quick test:

in the file dynamicTopoFvMesh.C
in the dynamicTopoFvMesh::resetMesh()you forget to remove the function

initFieldTransfers
(
fieldTypes,
fieldNames,
sendBuffer,
recvBuffer
);

Regards,

Olivier

Not sure I follow. That function is required.

Dear Sandeep:

Oh sorry, I am stupid, I made a mistake:

Regards,

Olivier

Alright - I took another look at this, and figured out the problem. I've pushed a fix, so it should work now.

Dear Sandeep:

Ok thank you, I will test today,

REgards,

Olivier

Hi Sandeep,

I wonder what were the modifications you introduced?.
I just updated my installation and I am running a first case and it seems that it is a way much slower, it is taking a lot time for computing the edge-bisection/collapse, before it was a way much faster.

Regards,

Joel

Joel,

You would need to quantify that - slower in what way? You might want to check if you got the length-scales right.