[deepsterblue]

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.

[mm.abdollahzadeh]

Originally Posted by deepsterblue

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

export MESQUITE_DIR=HOME/OpenFOAM/Mesquite
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$MESQUITE_DIR/lib

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

[georg]

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

[deepsterblue]

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

[georg]

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

[Aleksey_R]

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?

[olivier_au_chili]

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;
}

[deepsterblue]

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.

[deepsterblue]

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.

[Aleksey_R]

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.

[olivier_au_chili]

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

[deepsterblue]

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.

[philippose]

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

[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

[olivier_au_chili]

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

[olivier_au_chili]

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

[philippose]

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

[georg]

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

[pcaron]

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

[deepsterblue]

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?