Dear Sandeep:

I am using OpenFoam 1.6-ext with your last version dynamicTopoFvMesh. I have no problem when it runs on 1 processor but when I use mpirun, I have this bug:

==> I found that there is a problem in dynamicTopoFvMeshCoupled.C initFieldTransfers here:
The others names[6] etc... seems to not generate problem.

I do not understand what is the problem, Can you help me please to solve this problem,

Thank you in advance,

Olivier

Olivier,

It's hard to tell from your error message. It looks like you're running with a solver that includes a surfaceScalarField that's being mapped. If you have a minimal case that reproduces the issue, perhaps I could take a look.

Also, you could set a higher debug level under the dynamicTopoFvMesh dictionary in dynamicMeshDict (goes from 0 up to 5, typically), and see if that gives you more information that I could use.

Dear Sandeep:

I am sorry for replying so late. I checked my program but I still have the same problem. I tested the tutorial projectile of the professor Kile Mooney with debug=5 and the problem is the same:


Regards,

Olivier

Greetings to all!

@Olivier: I've seen this kind of issue before, but not with dynamicTopoFvMesh.
Usually this is due to a custom boundary condition that does not correctly support the division of patches between processors.

If you cannot provide a simple test case as Sandeep asked for, please describe in some detail the types of patches/boundary conditions you are using and what types of dynamic mesh schemes and options you are using.

Best regards,
Bruno

Dear Wyldckat:

As I wrote, I used the tutorial named "projectile" developed by Kile Mooney. This tutorial uses SIXDOF and dynamicTopoFvMesh. I believe that this tutorial was presented at the 7th OpenFoam workshop and it can be found with Caelinux.

This tutorial works without problem with the previous versions of dynamicTopoFvMesh. Unfortunately with this latest version and with my program the remeshing does not work.

In the both cases I have the same error.

Regards,

Olivier

Hi Olivier,

I was going to try and reproduce the same error you're getting, but I remembered that there are some unknowns I would like to check with you:

1. The 1.6-ext build you are using, is indexed to which commit on git? You can run the following commands to see this:
   
   Code:

   ---

   foam
git log -1

   ---

2. Are you using the default Mesquite version that 1.6-ext uses or have you upgraded it?
3. How exactly did you integrate/build the latest "dynamicTopoFvMesh" from https://github.com/smenon/dynamicTopoFvMesh into 1.6-ext?

Best regards,
Bruno

Hi Bruno

As I was using a oldest version, yesterday I did a clean reinstall of openFoam-1.6-ext, following the tutorial:
http://openfoamwiki.net/index.php/In...u#Ubuntu_12.10 since I have wheezy.

i) I use a default Mesquite version
ii) I install dynamicTopoFvMesh in my directory OpenFoam outside of the directory OpenFOAM-1.6-ext. I followed the installation instructions described by Sandeep Menon: steps 1,2,3 and git clone https://github.com/smenon/dynamicTopoFvMesh etc.
iii) The libraries of dynamicTopoFvMesh are built in $FOAM_USER_LIBBIN / $FOAM_USER_APPBIN

I obtained the same results as described above this post.

Thank you for your help,

Olivier

foam-extend-3.0 & dynamicTopoFvMesh-git
 

Apologies for my lack of understanding, I am a relative newcomer to c++. I am seeing an error I do not understand given the easy installation instructions for dynamicTopoFvMesh.

First off, I followed Bruno's instructions for foam-extend installation just a couple changes in order to compile in Debug.

1. All Bruno's steps up to and including the execution of ./Allmake.

2. But, before executing

... I took the following two steps:

(a) Created symbolic links such that:

(b) Alter etc/bashrc such that it reads:

3. Continued with Bruno's remaining steps.

Then, I downloaded and installed the git version of dynamicTopoFvMesh, as per Sandeep's Install.txt.

4. Executed:

5. Go to the checked-out directory and compile:

6. Prepare to test the installation:

7. Make the top of constant/dynamicMeshDict look like:

8. Solve

What am I doing wrong? Much appreciated, Eric

Edit:
The same fatal warming/fatal error sequence occurs when using a installation of foam-extend-3.0 compiled for Opt.

Hello Eric,

I apologize - I forgot to update the instructions. You will need to remove the dynamicTopoFvMesh files from the foam-extend-3.0 source and recompile the dynamicFvMesh library. You may want to do that with the mesquiteMotionSolver library as well.

The reason you're seeing the failure is due to conflicting sources - I'm still trying the figure out the most optimal way to have things side-by-side.

recompiled dynamicTopoFvMesh, not so much mesquiteMotionSolver - perhaps?
 

Hi Sandeep -

Ok I have followed the old version directions -

https://github.com/smenon/dynamicTop...b1/Install.txt

... which changes my log.moveDynamicMesh to:
... perhaps associated with not having:

Edit #1: Tried
... but saw same undefined symbol error.

Edit #2: Immediately after Edit #1, tried
... but got error (attached).

Very much appreciate your responsiveness, Eric

Eric,

Use 'wmake libso', not just 'wmake'.

You should ensure that Mesquite is installed correctly - your log seems to suggest otherwise.

Dear Sandeep,

I am using OpenFoam 1.6-ext with your latest version of dynamicTopoFvMesh. I am currently trying to simulate two leaflets rotating in a chamber. The model is currently not made to scale. My plan is to eventually perform a FSI simulation on a bi-leaflet valves in a heart chamber, using pimpleDyMFoam. My sample case can be downloaded here (5MB):
https://dl.dropboxusercontent.com/u/...73K_sample.zip

I have not started on the 6DoF FSI simulation as I am just evaluating to see if the mesh is able to rotate fully and that the mesh quality is okay throughout the cycle. I use moveDynamicMesh and allow edgeRefinement 'yes' as mentioned in an earlier post that may cause the cell not grow properly and collapse. However, I still encountered the issue of negative cells as mentioned by Bruno earlier. I've also checked to ensure that the length scale for the two leaflets 'wing_1' and 'wing_2' patches match the dynamicMeshDict. I am not sure what went wrong. I thought that the reason might due to that the wing_1 and wing_2 being rotated faster than the mesh changes so I let both the patches to rotate slowly but it seems like it wasn't the case. How should I proceed to work on the FSI simulation of the two leaflets?

Hoping to hear your views/comments.

Best wishes,
Han

Error message
This is my dynamicMeshDict

BC for FSI
 

Hi Sandeep -

Initially I believed that dynamicTopoFvMesh (used with the mesquite motion solver) needed a very explicit surface to mesh against -- e.g. a function defining the solid surface, or an stil surface.

But then, I noticed your recommendation of the use of dynamicTopoFvMesh for a FSI case...

So, here's the question:

Inside my:

... there exists a boundary condition:

Is this BC also usable, in this way as a fluid BC for dynamicTopoFvMesh? I'm specifically thinking with regards to the icoFsiFoam solver.

Parenthetically, I am not the only one with these questions, see this post.

Anyway - thanks for bearing with me. I'm hoping to not make 'wmake libso' beginner mistakes, for all that much longer.

Best, Eric

Hans,
It looks like the mesh was inverted before the motionSolver was called, so you may want to check your boundary motion to ensure that it is correct.

Eric,
Yes, you can use any boundary condition you like - no limitations.

posted mesquite-2.1.2.tar.gz
 

Hi all -

I was recompiling foam-extend from source. Noticed that the wget of mesquite is currently down. (This takes place during the ThirdParty compile.)

Perhaps someone will find the link to the mesquite-2.1.2.tar.gz tarball useful.

Best, Eric

Dear Joegi and Sandeep,

I am sorry to bring up this issue again, but is that problem solved?

Dear Sandeep,

I have used the timeVaryingDisplacement patchField suggested by you earlier. Now the mesquiteMotionSolver predicts the motion just fine. But there is an another strange behavior when I use dynamicTopofvMesh besides with mesquiteMotionSolver.

My results:

moveMesh --> Predicts the motion just fine (but there is no re-meshing of course)

moveDynamicMesh --> Re-meshing occurs but the motion is less that what expected.

P.S: I am using openFOAM 2.3

Well, just tested on foam-3 and got it working successfully.
the "timeVaryingDisplacement" method worked just fine in foam-3.

However I wonder why it didn't work on openFOAM 2.3 ?! As I mentioned in my previous post, the mesquiteMotionSolver works just fine when it is used alone by running "moveMesh", but when I use moveDynamicMesh, the actual displacement is somewhat less than the desired displacement (maybe 20% less). This is strange because the same case worked just fine in foam-3.

After all these, I started to solve for flow and I have encountered a new problem. As long as dynamic mesh is fine in foam-3 I tried to use this version to solve for fluid flow, but here is my output:

On the other hand, when I use openFOAM 2.3 (of course with wrong motion as mentioned before) flow is solved just fine.

Not to mix up as a conclusion,

foam-extend-3.0 --> (True mesh dynamics) And (Core dumed while solving for fluid flow)
OpenFOAM-2.3 --> (Right motion of the mesh when using moveMesh) And (wrong motion of the mesh when using moveDynamicMesh) And (Solving for fluid flow with no problems)

Never mind, I just pulled to the latest update in foam-extend-3 and everything worked just fine.

Sandeep, I want to thank you for this incredible tool, its great :).

Dear FOAMers,
I have a problem with the dynamicTopoFvMesh developed by Sandeep Menon.
The aim of my work is to develop a solver within the OpenFOAM framework for the simulation of the combustion of spherical/cylindrical particle of biomass. To reach this object I have to introduce a moving mesh in order to allow the shrinking of the particle. I use OpenFOAM 3.1-ext. I have developed a new class (named shrinkingParticle) that allows the movement of the all points on the surface. I have used these libraries for the mesh motion and I have introduced my class as BC for the surface points in the fixedValuePatches of the dynamicMeshDict.
To test this new tool, I have used the moveDynamicMesh and it works very good.
I have problems when I add some calculations together with the mesh motion.
For instance, I have added the simple temperature laplacian after the mesh update:
I have imposed an internal temperature of 300 K and a boundary value of 700 K.
The temperature must be bounded in this range [300-700], but with the mesh motion my solution exceeds these values.
I've attached the dynamicMeshDict and the spherical tet mesh that I use. I have noted that the solution is very sensitive at the kind of function that I insert in the mesquiteOptions. Maybe, I adopt incorrect options within the dictionary, but I have no idea how fix my problem.
Can anyone help me, or give me any tips?

Thank you so much for the attention

Best regards
Giancarlo Gentile