Quote:
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: Code:
Processor priority: 2(0 1) Code:
// Subset and send surfaceFields to stream 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: Code:
2 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:
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 Code:
source etc/bashrc (a) Created symbolic links such that: Code:
ln -s $WM_THIRD_PARTY_DIR/packages/hwloc-1.7.2/platforms/linux64Gcc46DPOpt $WM_THIRD_PARTY_DIR/packages/hwloc-1.7.2/platforms/linux64Gcc46DPDebug Code:
: ${WM_COMPILE_OPTION:=Debug}; export WM_COMPILE_OPTION Then, I downloaded and installed the git version of dynamicTopoFvMesh, as per Sandeep's Install.txt. 4. Executed: Code:
mkdir -p $WM_PROJECT_USER_DIR/run/dynamicTopoFvMesh $FOAM_USER_LIBBIN $FOAM_USER_APPBIN Code:
cd $WM_PROJECT_USER_DIR/run/dynamicTopoFvMesh Code:
cp -r ~/foam/tutorials/mesh/moveDynamicMesh/circCylinder3d $WM_PROJECT_USER_DIR/run/ Code:
dynamicFvMeshLibs ("libdynamicTopoFvMesh.so"); Code:
./Allrun 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?
1 Attachment(s)
Hi Sandeep -
Ok I have followed the old version directions - https://github.com/smenon/dynamicTop...b1/Install.txt ... which changes my log.moveDynamicMesh to: Code:
moveDynamicMesh: symbol lookup error: /home/eric/foam/foam-extend-3.0/lib/linux64Gcc46DPDebug/libdynamicFvMesh.so: undefined symbol: _ZN4Foam9coupleMap8typeNameE Quote:
Code:
cd $FOAM_SRC/dynamicMesh/meshMotion/mesquiteMotionSolver Edit #2: Immediately after Edit #1, tried Code:
cd .. 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 Code:
leo@leo-laptop:~/OpenFOAM/leo-1.6-ext/run/mesh/leaflets_273K$ moveDynamicMesh >log.run1 Code:
/*--------------------------------*- C++ -*----------------------------------*\ |
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: Code:
~/foam/foam-extend-3.0/tutorials/solidMechanics/deprecatedTutorials/icoFsiFoam/flappingConsoleSmall/fluid/0/U Code:
consoleFluid 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 |
Quote:
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: Code:
/*---------------------------------------------------------------------------*\ 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 :). |
2 Attachment(s)
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: Code:
mesh.update(); 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 Code:
|
Hello Giancarlo,
Perhaps you could print out your "T" field after mesh.update() and see if the values are within the range that you expect? I'm looking to see if the field remapping after topology changes is correct. Thanks, Sandeep |
Hello Sandeep,
thanks for your reply. I have checked the temperature field after the mesh.update and the remapping seems to work well. I insert what I see from the bash Code:
Create time Best regards Giancarlo |
This then suggests that you have problems in your solution set up. You should check your schemes and boundary conditions. Since you're solving a laplacian, do you have fixedValue boundary conditions? You might have a saddle-point problem otherwise.
|
Yes, I have fixedValue BC for temperature field:
Code:
dimensions [0 0 0 1 0 0 0]; Code:
ddtSchemes |
2 Attachment(s)
Hello Sandeep,
I worked about the problem that I explained you last week, but I think that it's not a problem of the discretization schemes. I have made a very simple case in order to better explain the discrepancy during the solution of the laplacian equation. My mesh is a box of 16 cells. I move only a face of the box in order to have the restriction of the initial volume. I set the temperature of the domain to 700 (boundary and internal field). Moreover, I compute the temperature laplacian: Code:
fvm::ddt(T) - fvm::laplacian(DT, T) If, I don't move the mesh the temperature is always constant to 700. The solver is able to properly solve the laplacian. On the other hand, if I set the mesh motion, I register no feasible temperature field. (the solution is not bounded to 700). I post the results, after the first iteration: Code:
Time = 0.01 Now, I'm working with OF-2.3, but I try to solve the same system with (OF-1.6-ext and OF-3.1-ext) and I have always the same problem. I think that, maybe, not all the mesh fields are updated with the mesh motion. Do you have any suggestion? I attach the test case and solver. Thanks in advance Best regards Giancarlo |
Hello Sandeep,
I am interested in using dynamicTopoFVmesh, but can't pull it from github for OF2.3.0 . Perhaps it is on purpose because of some updates of the files or something like that. In that case don't mind this post. If i try to pull dynamicTopoFVmesh for OF2.3.x I get the Version for OF-ext instead. By clicking the link for OF2.3.x a pretty cool Tatooine error 404 shows. (for everybody who has 2 Seconds time here is the link ;) https://github.com/smenon/dynamicTop...new/Port-2.3.x ) kind regards Alex |
You need to do this to switch to the Port-2.3.x branch after a git clone:
Code:
git checkout Port-2.3.x |
Thanks for the fast reply.
With your hint I tried the clone command with following option. Quote:
kind regards Alex |
Quote:
Best regards, Antonio |
Hello Antonio,
Could you use this option in mesquiteMotionSolver (under mesquiteOptions in constant/dynamicMeshDict): Code:
usePointDisplacement yes; |
1 Attachment(s)
Quote:
Hello Sandeep, actually I'm playing around with different mesh motion methods in OpenFOAM. Therefore I've created a simple test case, which is a carman flow around a moving cylinder (see attachment) At first I've run moveDynamicMesh without boundary motion to optimize the mesh (as you recommended), afterwards I enabled the boundary motion and run the simulation with pimpleDyMFoam (adjustTimeStep enabled). Regarding to your post this will fail due to the adjustable time step and the way you've implemented the mesh motion. Thats why I changed "refPoints_ += dPointField" to "refPoints_ = dPointField". But with both versions of the dynamicTopoFvMesh library (of31 and your git version) I get a floating point exception. Is there any other way to fix this except the timeVaryingDisplacement patchField? How can I achieve the full range of available patchFields? Best regards Matthias |
3 Attachment(s)
Dear all,
I'm a Ph.D. student of chemical Enginnering. The aim of my work is to develop a solver within the OpenFOAM framework for 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'm currently working with the dynamicTopoFvMesh library developed by Sandeep Menon and it works very good for a sphere, but I have several problems for the cylinder. For sake of clarity, I attach you the picture of my mesh at time 0. I have three boundary patch (inlet, outlet, lateralSurface) and I need to move, at the same time, all the point of each boundary with a prefix velocity along the face normal direction. As you can see from the second picture that I've attached, the mesh does not evolve with a uniform shrinking in both directions (axial and radial), but the border points, that belong at the same time to two different patches, seem to move with different velocity. My question is, Is it possible to perform this kind of mesh shrinking with this library? I attach you my case, I use moveDynamicMesh as solver. Thanks in advance Giancarlo Attachment 44948 Attachment 44949 Attachment 44950 |
Quick answer @Giancarlo_IngChimico: I haven't done the math nor tested the case yet, but I'm guessing that the problem is that the sides must be defined to move at 50% the speed of the cylinder.
I suggest that you do a test in ParaView and use the Transform filter to scale down to 0.5 on all directions and then check what were the distance changes that occurred on each surface. By the way, which OpenFOAM version are you using? |
Dear Bruno,
Currently I'm using openFoam 2.3.x. Thanks for your help. In my opinion the border points are update twice depending the patch order in the fixedValuePatches subDict. It leads, for some reason, a no uniform mesh motion in both radial and axial coordinates. Quote:
|
1 Attachment(s)
Hi Giancarlo,
I've tried to run your case with the following software stack:
The first suspect is the "toPoints" function: http://openfoamwiki.net/index.php/Co...s_are_defined: Quote:
Quote:
This can easily occur, because OpenFOAM's main calculations are done on the faces and cells. And since these points on the edges are common to 2 boundaries and not only one, it currently has no other way to assign dedicated boundary conditions for a group of points. Therefore, you will need to do specific calculations for the points on the edges of the cylinder... although I haven't really thought about how that can be done with GroovyBC :( A quick thinking about it leads me to believe that you can use "inline-if" conditions for defining how calculations are done based on specific conditions. And those conditions you can calculate only for the final boundary. Hopefully you can draw ideas from here: https://openfoamwiki.net/index.php/C...Usage_Examples The other possibility would be to rely on pointSets to manipulate specific point groups and assign dedicated point conditions to them. Best regards, Bruno |
3 Attachment(s)
Dear Bruno,
thanks again for your help. Today I've fixed my problem. dPointField defined in the file mesquiteMotionSolver.C is a pointField where all points displacement are stored. This field doesn't take into account multiple displacement of border points but is being overridden by the final boundary condition that, in my case, is done on "lateralSurface" patch. Adding multiple movements (radial and axial) of the border points in the dPointField , I've fixed my problem. Currently I can mange shrinking of my cylinder both in radial and axial directions. Nevertheless, I have another problem with the surface smoothing. Fist of all, I tried the mesh motion specifying only the outlet and inlet patches in the slipPatches subDict, as follow. HTML Code:
slipPatches In the second test, I perform the mesh motion with the following slipPatches subDict HTML Code:
slipPatches At the end, I added all my patches in the slipPatches subDict HTML Code:
slipPatches In other words, it seems the dynamicTopoFvMesh has a bug in multiple patches smoothing. Do you have any idea about these strange behavior? Thanks again Giancarlo Attachment 45059 Attachment 45060 Attachment 45061 |
2 Attachment(s)
Hi Giancarlo,
Sorry for the late reply, but only today did I finally manage to take a better look into your question. If my memory doesn't fail me, the "slip patches" feature is for defining the patches that allow the mesh to slide along those patches. For example, attached are two images from OpenFOAM's tutorial case "mesh/moveDynamicMesh/SnakeRiverCanyon", where:
This was possible in this case, because these 4 patches have strict normal definitions that allow the calculations to be performed properly. But in your case, dynamicTopoFvMesh is trying to deduce the normal directions automatically, but since all directions are changing simultaneously, it's not able to know for certain which side is up, because everything is changing. I don't know if you've figured out how to solve these issues, but I believe that the trick is to use a boundary condition that uses the original position as a reference for all other iterations. But this will likely require coding said boundary condition. Best regards, Bruno |
Hi all,
I am trying to use dynamicTopoFvMesh to refine a mesh (tets) around a surface in a VOF method with or without the mesquite smoother. Does anybody have a testcase where this is done in a small scale application? At the moment I am trying figure out what the correct settings in the dynamicMeshDict are. However, I am not experinced with the tool and I dont have a runing test case and the default setting seem not to work. Therefore, it is a lot of try and error. If anybody has experince with the field refinement tools of dynamicTopoFvMesh and or a testcase. I would be glad about some input. Best Arne |
Hello Bruno and Sandeep,
did you figure out the 6dof problem in this 'volvmov-topo' case sincerely daron Quote:
Quote:
|
Quote:
Depending on what you want to do, perhaps it's best that you look into the Overset Mesh feature in OpenFOAM.com (not OpenFOAM.org which doesn't have this feature yet :( ). |
All times are GMT -4. The time now is 12:07. |