|
[Sponsors] |
topoChangerFvMesh/movingConeTopoFvMesh+pimpleDyMFoam pressure problems |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
April 2, 2012, 18:30 |
topoChangerFvMesh/movingConeTopoFvMesh+pimpleDyMFoam pressure problems
|
#1 |
Senior Member
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 740
Rep Power: 28 |
I've been working with topoChangerFvMesh/movingConeTopoFvMesh with pimpleDyMFoam to practice implementing some mesh and topology changes, as I figure using a simpler topoChanger with incompressible flow would help me more fully understand how to get it working for engine combustion cases. I"m using 2.1.x as I will eventually need to use the new lagrangian spray libraries.
I've adapted pimpleDyMFoam to use the topoChangerFvMesh (pretty much just including headers and linking with the library) and have changed the movingConeTopoChangerFvMesh so that the velocity in the x-direction is constant; that way I can match the pimpleDyMFoam tutorial case. The case runs and layer/addition removal works great, but the solution variables are totally off. I am currently slogging through the polyTopoChanger code but its slow going and I'm still unclear on A LOT of the underlying machinery. Has anyone used mesh topology changes in the official branches from 1.7 onwards? I could really use some help with: 1) Where the problems are occurring (is it the polyTopoChanger engine or the solver?) 2) Can I fix this in the solver or will the topoChangerFvMesh need modifications? Anyone with any experience in doing simulations with topology changes would be very helpful. Thanks! EDIT: On a lark, I thought I'd look at the User Guide for versions 1.5-2.0, and it appears that topoChangerFvMesh has been made "redundant" since about 1.6. So it looks like I'm in for more trouble. Last edited by mturcios777; April 2, 2012 at 19:09. Reason: topoChangerFvMesh deprecation? |
|
April 2, 2012, 22:03 |
|
#2 |
Senior Member
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 403
Rep Power: 25 |
Since you seem to be adamant about using 2.1.x, can you at least try the extend version for a simple case with layering to ensure that the basics (like pressure / field-mapping) work?
Again, I'll insist - there are several differences at a fairly fundamental level between the extend / OpenCFD version as far as topo-changes are concerned, so I'm not surprised that you're running into trouble. Simply slapping-in the extend version and somehow convincing it to compile is not necessarily going to solve the issue. |
|
April 3, 2012, 15:34 |
|
#3 |
Senior Member
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 740
Rep Power: 28 |
Thanks for the reply Sandeep. I have checked out the extend version and the layering does work for both the simple movingCone case as well as the more complicated (but not by much) engineTopoChangerMesh, with the field mapping and solving working just fine. The mapping in 2.1.x works as expected, but the pressure variable gets messed up after the subsequent solve iteration.
Note that I'm using the topoChangerFvMesh which is included with the default 2.1.x installation, using Code:
dynamicFvMesh movingConeTopoFvMesh; Migrating to 1.6-ext for the topoChanges would be a possibility but would involve a lot of changes on our end and the loss of some functionality (or reprogramming it), but if its the only way then there isn't much I can do about it. I would like to make sure I've exhausted all my options, as I find it hard to believe no one has used 2.1.x to simulate topology changing meshes. |
|
April 3, 2012, 15:42 |
|
#4 |
Senior Member
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 403
Rep Power: 25 |
Fair enough. This means that 2.1.x has bugs when topology changes are involved, and you may want to file a bug-report with them, along with a minimal test-case that reproduces the issue.
I get the suspicion that any changes are not going to be trivial, and you'll have to pay for support to get it resolved. Hard pill to swallow, but that's how things work sometimes. |
|
May 18, 2012, 10:29 |
|
#5 |
Senior Member
Samuele Z
Join Date: Oct 2009
Location: Mozzate - Co - Italy
Posts: 520
Rep Power: 18 |
Hi All,
I have created 3 meshes with the Fluent-mesher and I would like to use the topoChangerfvMesh in order to make it possible to study my problem on that moving geometry. Could anyone explain how to `link' the different meshes? Thanks a lot, Samuele |
|
May 18, 2012, 12:49 |
|
#6 |
Senior Member
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 740
Rep Power: 28 |
Hi Sam,
The topoChangerFvMesh is a general family of classes that combines a dynamicFvMesh with appropriate polyTopoChangers. In the current OF documentation under "Standard Libraries", this library is listed as redundant; I'm not sure the reasoning, but I suspect because it is easier for users to make their own classes that change topology based on their specific needs. The topology changers that I have seen are in the $FOAM_SRC/dynamicMesh folder. So far I have played with (in OF21x): attachDetach layerAdditionRemoval I've managed to get attachDetach working for incompressible flow, still working on compressible; you can read about it here. I haven't got layerAdditionRemoval to work yet, I think there are some deeper issues that need to be worked on by someone with a better understanding of the underlying mesh structure. Unless you absolutely need topological changes (like me), I would advise you to use the dynamicFvMotionSolver meshes if at all possible, as they seem to be fully functional at this time. Good luck! |
|
May 21, 2012, 03:45 |
|
#7 |
Senior Member
Samuele Z
Join Date: Oct 2009
Location: Mozzate - Co - Italy
Posts: 520
Rep Power: 18 |
Dear Marco,
thanks for your help. So, what should I do, now? I have 3 meshes (I can share them with you, if you five me your email) and I need to `link' them. The point is that I can not understand which is the dictionary that I have to write in order to make the simulation of the mesh-motion. Thanks a lot, Samuele |
|
May 22, 2012, 16:40 |
|
#8 |
Senior Member
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 740
Rep Power: 28 |
Sam,
Have a look at $FOAM_TUTORIALS/incompressible/pimpleDyMFoam/movingCone/constant/dynamicMeshDict to get started. This uses the dynamicFvMotionSolver dynamic meshes, but there are all kinds that can be used. When you say you need to "link" the meshes, do you mean topologically connect them? Judging from past messages on other threads, it seems like you want to use the different meshes at different points in time. Post a message in this thread with a quick answer, then send me a message with your case with more details. |
|
May 23, 2012, 02:55 |
|
#9 | |
Senior Member
Samuele Z
Join Date: Oct 2009
Location: Mozzate - Co - Italy
Posts: 520
Rep Power: 18 |
Quote:
Ok, I'll send you a message. Thanks a lot, Samuele |
||
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Pressure Outlet Guage pressure | Mohsin | FLUENT | 36 | April 29, 2016 17:16 |
Fluent natural ventilation pressure boundary condition | pierresandre | FLUENT | 24 | November 8, 2011 14:32 |
Problems with extrapolation of pressure in BC | Sergio | Main CFD Forum | 0 | July 17, 2008 09:05 |
Pressure Boundary Problems | Chris | Siemens | 2 | June 21, 2005 08:20 |
what the result is negatif pressure at inlet | chong chee nan | FLUENT | 0 | December 29, 2001 05:13 |