CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Programming & Development

topoChangerFvMesh/movingConeTopoFvMesh+pimpleDyMFoam pressure problems

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   April 2, 2012, 18:30
Default topoChangerFvMesh/movingConeTopoFvMesh+pimpleDyMFoam pressure problems
  #1
Senior Member
 
mturcios777's Avatar
 
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 727
Rep Power: 18
mturcios777 will become famous soon enough
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?
mturcios777 is offline   Reply With Quote

Old   April 2, 2012, 22:03
Default
  #2
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 386
Rep Power: 15
deepsterblue will become famous soon enough
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.
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is offline   Reply With Quote

Old   April 3, 2012, 15:34
Default
  #3
Senior Member
 
mturcios777's Avatar
 
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 727
Rep Power: 18
mturcios777 will become famous soon enough
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;
in dynamicFvMeshDict, so for this case I'm not migrating anything from 1.6-ext. I figured if I could get the included version to work with incompressible flow I would gain the understanding necessary to start getting compressible flow to work. I only tried "slapping in" the extend version as a very first test, whereupon I discovered there was more to this than meets the eye (surprise surprise).

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.
mturcios777 is offline   Reply With Quote

Old   April 3, 2012, 15:42
Default
  #4
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 386
Rep Power: 15
deepsterblue will become famous soon enough
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.
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is offline   Reply With Quote

Old   May 18, 2012, 10:29
Default
  #5
Senior Member
 
Samuele Z
Join Date: Oct 2009
Location: Mozzate - Co - Italy
Posts: 490
Rep Power: 9
samiam1000 is on a distinguished road
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
samiam1000 is offline   Reply With Quote

Old   May 18, 2012, 12:49
Default
  #6
Senior Member
 
mturcios777's Avatar
 
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 727
Rep Power: 18
mturcios777 will become famous soon enough
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!
mturcios777 is offline   Reply With Quote

Old   May 21, 2012, 03:45
Default
  #7
Senior Member
 
Samuele Z
Join Date: Oct 2009
Location: Mozzate - Co - Italy
Posts: 490
Rep Power: 9
samiam1000 is on a distinguished road
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
samiam1000 is offline   Reply With Quote

Old   May 22, 2012, 16:40
Default
  #8
Senior Member
 
mturcios777's Avatar
 
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 727
Rep Power: 18
mturcios777 will become famous soon enough
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.
mturcios777 is offline   Reply With Quote

Old   May 23, 2012, 02:55
Default
  #9
Senior Member
 
Samuele Z
Join Date: Oct 2009
Location: Mozzate - Co - Italy
Posts: 490
Rep Power: 9
samiam1000 is on a distinguished road
Quote:
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.
That's right: I would like to connect 3 meshes that are different in time.

Ok, I'll send you a message.

Thanks a lot,

Samuele
samiam1000 is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Pressure Outlet Guage pressure Mohsin FLUENT 34 January 12, 2012 06:45
Fluent natural ventilation pressure boundary condition pierresandre FLUENT 24 November 8, 2011 15:32
Problems with extrapolation of pressure in BC Sergio Main CFD Forum 0 July 17, 2008 09:05
Pressure Boundary Problems Chris CD-adapco 2 June 21, 2005 08:20
what the result is negatif pressure at inlet chong chee nan FLUENT 0 December 29, 2001 06:13


All times are GMT -4. The time now is 15:11.