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 19:26. |