Moving mesh theory

julia.hartigjulia.hartig Member
edited January 11 in Fluids

Hey all,

I'm currently working on two multiphase (gas-solid) flow simulations - one in the open-source code MFIX, the other in ANSYS Fluent. The mesh movement itself is fairly simple rigid body translation (no mesh topology changes). I've already got a moving mesh simulation going in Fluent with UDFs, as you can see below. This is a simplified single-phase case, but should give you a feel for the kind of mesh movement we have.

Mesh movement:

Flow field solution:

Doing this in MFIX is a big challenge because I need to code the mesh movement myself. The ANSYS theory guide only provides a very general description of moving mesh theory in section 3.2.1 (see attached), which is not enough for me to understanding coding backend questions like "how and when are new mesh cell positions calculated and stored", "how does the mesh velocity influence the convection terms in the SIMPLE algorithm", etc.

I've been trying to learn how this is done with the only moving mesh CFD packages I know - OpenFoam and ANSYS. OpenFOAM has classes that do this operation for you "in the background" like ANSYS (i.e. solidBodyMotionFvMesh) so I'm not finding detailed information about how to do this yourself, in another program.

My understanding is I would need code that:

  1. Determines the new mesh point positions from the old ones at each time step. Many CFD solvers use adaptive time stepping (i.e. not a fixed dt) so maybe you have to do this on-the-fly?
  2. Reformulates the governing equations in terms of relative velocity between the fluid and the moving mesh
  3. Maybe calculates some correction terms for fluid and solid-phase variables (i.e. if mesh moves and particle is now out-of-bounds, update its position)

If this sounds incorrect, or if I'm missing any steps, please let me know! I'm especially worried about doing step 2 correctly. If you have any papers or textbooks you can point me to, that is what I'm looking for! My Google search results on these topics have not been very helpful.


  • RobRob UKForum Coordinator

    Whilst this isn't strictly an Ansys question I'll leave it open as it is simulation based. Re the Fluent moving mesh, the Theory Guide will give some details but won't cover the coding side of things: that's our (commercial) knowledge. Add in the optimiser and other solver technology and you get an efficient reliable solver (Fluent and CFX).

  • Hello,

    I have never wrote my sliding mesh code, but I am trying to think with you.

    If you add layering subroutine to your CFD code ... what would you need? let's start by a simple case where one boundary moves and we are going to check the adjacent cells

    First, you need to find the new boundary position ... then you need to check each of the boundary cells , do they meet the criteria to merge/divide ... if yes, you are going to define the new size of the boundary mesh and the layer before. As the size changes, you have new fluid in some cells and less fluid in others ... can we compensate this by a source term?

  • Rob,

    Since there are no citations in this theory manual section, I was hoping an ANSYS developer could point me to a reference they had "missed" in the theory guide, something like the "Numerical heat transfer and fluid flow" book by Suhas Patankar but for moving meshes. It sounds like that's not the case, that's too bad. The numerics (convection terms in SIMPLE) is the part I'm most worried about, and I don't know how I would even validate that I'd done it correctly once I implemented an algorithm.


    I think the situation you are talking about with merging/dividing cells would be a mesh topology change scenario. That is definitely more complicated. Fortunately we don't have any mesh topology changes here (no cell volume changes) - just rigid body translation of the moving mesh.

  • So, in this case, I believe your procedure would be right. You need to determine the new mesh position .. so you know the new neighbours. Apply conservation equations with the relative velocity.

    I can see the difference will be only that every cell at the interface will have different neighbours and different contact area with those neighbours.

    Regarding the relative velocity, you can use the same subroutine of stagnant mesh, but pass the relative velocity instead of the absolute.

  • @julia.hartig

    validation could be by comparing your results with ansys .. do Fluent simulation and extract the velocities, pressures and compare it with yours.

  • @Rob Perhaps a more ANSYS-specific question would be: since there are no citations, how/where was the relative velocity formulation in section 3.2.1 derived? And has this been validated against test cases? For example, I can see this working for a constant-velocity mesh, but what about a constantly-accelerating (i.e. vibrating) mesh? Does this put you in a non-inertial reference frame, and if so, under what circumstances can these "non-inertial" effects influence your solution, or maybe introduce more terms to the RANS equations that must be accounted for?

    @YasserSelima Ah okay, I like the relative velocity idea! Then maybe I don't need to worry about mesh position updates, except with respect to sliding interfaces. Our new system does not have any sliding interfaces (the whole domain moves along a 2D sinusoidal excitation with rigid body translation) so that simplifies things. Maybe the best approach to get details about the numerics is to study the solidBodyMotionFvMesh routine in OpenFOAM. I've been apprehensive about doing this because my C++ is rather limited, and I would need to learn the entire OpenFOAM solver architecture... but, if ANSYS doesn't have resources on this, that may be my best option.

  • don't worry about C++ if you are familiar with Fortran or other compiled language. All you need is just few hours reading commented codes and you will be professional. I wrote my first C++ code as a UDF and it didn't take me more than few hours to write my first function.

  • DrAmineDrAmine GermanyForum Coordinator

    Moving control volume conservation equation are standard equations applying Reynolds Transport Theorem using relative velocity. The guide just highlight some high leven information without going into details.

  • @DrAmine That makes sense. Would this formulation still be valid for an accelerating mesh? And are the divergence/gradient terms also in terms of relative velocity (i.e. d/d(u-ug)) or absolute velocity d/du? This is where I can see issues happening - if d/d(ug) is nonzero, evaluating a d/d(u-ug) term in something like the fluid shear stress term is quite complicated, isn't it?

    @YasserSelima I've done some C++ and Fortran subroutine coding before without too much difficulty. My concern is usually with subroutine-to-subroutine communication, since the mesh velocity formulation will affect multiple subroutines. Poorly-documented codes don't always explain the highest-level subroutine and calling structure, so I hope I don't miss any subroutines that need to be modified. Maybe I will get lucky and this will not be so hard!

  • @julia.hartig sounds very interesting project. Good luck!

  • RobRob UKForum Coordinator

    I've used the functions for diaphragm motion and we've got fairly extensive validation data (not all public) for a range of tests with moving mesh. As you move from the high level equations @DrAmine pointed out we get into the Ansys know-how which we're not sharing!

  • @Rob that is understandable, I just want to make sure I understand the current formulation of ANSYS moving mesh theory well enough that I can be confident I will not violate any physics if I apply this to my system!

  • RobRob UKForum Coordinator

    Part of the fun is violating the laws of physics. There's a reason we use computers and aren't allowed in labs.... 😀

  • DrAmineDrAmine GermanyForum Coordinator


    I am pretty sure all of these concerns are taken into account but nothing is mentioned in the documentation . There are several references talking about derivation of numerical algorithms for moving grid which you might have a look into.

  • @Rob Haha but that's the problem! I run the experiments too, so if I try to compare the two ~6 months down the road and they don't match, it might be hard to pinpoint why.

    @DrAmine Okay that's exactly what I was looking for and missing! Where are you seeing those moving grid numerical algorithm citations? I can't find them in the theory manual, maybe I'm looking in the wrong spot.

  • With all my respect to Ansys and all the researchers working there, casting doubt is part of the research process. I understand that for-profit organisations can not publish every thing because of the competition.

    @julia.hartig continue to ask questions when ever you feel confused. That is how you would be able to defend your work. Sometimes you will get answers, and sometimes you won't ... but keep asking.

  • DrAmineDrAmine GermanyForum Coordinator

    DOI: 10.2514/6.2009-341 and are two good references with basic and advanced level. Details how the algorithm is looking like including updating mesh, interpol correcting face flux relative to motion can also be found.

  • @DrAmine Great thank you, I'll check these out!

Sign In or Register to comment.