topoChangerFvMesh/movingConeTopoFvMesh+pimpleDyMFoam pressure problems
 

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.

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.

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
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.

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.

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

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!

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

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.

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