[ander]

Hi all,

I'm investigating possible ways that the aerodynamics around a projectile modelled as a rigid body could be solved. This would consitute a coupled 6DOF/CFD solver. The main challenges are related to the CFD simulation.

The mesh will obviously have to follow the projectile since meshing its entire flight path would be infeasible. This means that the mesh will at least have to undergo unsteady translation, and fictitious body forces would be appropriate to account for linear acceleration of the mesh.
At this point a choice has to be made. Shall the projectile rotate inside the mesh (which would require a chimera grid or perhaps ALE formulation with remeshing or some kind of immersed boundary method), or is it better to let the grid rotate rigidly with the projectile? The latter approach would require fictitious forces associated with rotation in addition to translation and would make it more complicated to impose farfield boundary conditions. The flow equations would be solved in the body frame of the projectile.

The latter approach seems more elegant and computationally efficient in my view, but there may be reasons that make it impractical. Please give me your opinions!

[sbaffini]

In general, if you have N bodies whose relative geometry is fixed and they, all at once, move together as a rigid body and no other body moving differently is present in your study, then a single non inertial reference frame is always able to describe the motion around such N bodies, so that you can use a fixed mesh.

In this case, a spherical domain around such N bodies is clearly the most flexible choice to handle all possible cases.

So, yes, whenever feasible (as in the case described above) the latter approach with fictitious forces has to be preferred over moving meshes and the like

[ander]

I thought so! Is there likely to be any numerical issues related to this procedure? For instance, high rotation rates or large radii away from the center of rotation will produce large source terms due to coriolis and centrifugal forces.

[sbaffini]

It really depends from the case.

Note that classical simulations are, in fact, performed in this frame of reference, but it doesn't accelerate. Yet, even adding a constant velocity to the frame can change certain scale resolving simulations, because the numerical methods have errors depending on the solution.

So, in general, yes, you will have differences due to the numerics. You can typically choose between a relative velocity formulation, the one described above, or an absolute velocity one, where you solve for the physical velocity and the source terms are different.

But moving mesh cases are dependent on the numerics too, and also add additional complexities. So, in the end, it needs to be analyzed case by case.

[sbaffini]

Let me highlight two main aspects.

When working in a moving frsme with a relative velocity formulation, you have 0 velocity on viscous walls. This may be important for accuracy. In contrast, the relative velocity formulation has terms that do not fit into the conservative formulation, which might be problematic.

I personally work with an immersed boundary code, and I have found the need of having 0 velocity at walls higher than anything else

[ander]

When you say terms that don't fit into the conservative formulation you mean the body force source terms centrifugal acceleration, coriolis and euler force? Interesting, I actually implemented a simple 2D ghost point immersed boundary FSI code for my master's thesis.

Any good suggestions for open source software that can be modified to perform the relative formulation I outlines above? I plan on using it for unsteady aerodynamics. I have looked into SU2, but it seems like all freestream parameters have to be predefined there, and it doesn't seem straightforward to set spatially varying boundary conditions. This seems problematic to me, since if the reference frame is translating the, freestream velocity has to change, and if it is rotating, the boundary velocity has to be spatially varying as well (spatially varying with the radius from the rotation center crossed with angular velocity).

Not sure about how these things are handlet in OpenFOAM, but from my research it seems like its high speed compressible solver selection is very limited compared to SU2.

[sbaffini]

I was referring to all the terms except the centrifugal one (which, instead, being a gradient, can be implemented in a conservative way)

The main problem with most immersed boundary codes is that they do not give you a 0 mass flux on walls, as the velocity is necessarily interpolated on the grid boundary. The error here is proportional to the grid spacing and, heuristically, the local velocity.

With grid refinement and a 0 wall velocity the error goes rapidly to 0 with grid refinement (as the interpolation point gets smaller velocities too). This is not anymore the case for a non 0 wall velocity, with the wall normal one being especially detrimental.

[ander]

I notices this myself, this seems to be the major downside of the method, but didn't know that about it being proportional. I also heard about cut cell methods which apparently are conservative, but they seem hard to implement, and perhaps they have other downsides that I'm unaware of.

[sbaffini]

Non 0 mass flux can be corrected (in the same way incompressible outflows are corrected) but, yes, cut-cell is ideally the best.

The problem with cut-cell is that to have a robust implementation you soon realize that it basically is no more simple than the actual grid generation problem. Nice to have, but just difficult to implement and really automate.

In the end, in my opinion, the goal for ib is to find the sweet spot where implementation is easy, the code robust and the results always within the accuracy of the method.

[sbaffini]

Originally Posted by ander

Any good suggestions for open source software that can be modified to perform the relative formulation I outlines above? I plan on using it for unsteady aerodynamics. I have looked into SU2, but it seems like all freestream parameters have to be predefined there, and it doesn't seem straightforward to set spatially varying boundary conditions. This seems problematic to me, since if the reference frame is translating the, freestream velocity has to change, and if it is rotating, the boundary velocity has to be spatially varying as well (spatially varying with the radius from the rotation center crossed with angular velocity).

Not sure about how these things are handled in OpenFOAM, but from my research it seems like its high speed compressible solver selection is very limited compared to SU2.

While I don't have a direct experience with it, I would also suggest SU2 as first attempt with compressible flows, before going to OpenFOAM.

As for the relative frame formulation, I have no idea. It is possible, indeed, that OF has more options on this, but I don't know this directly neither.

In any case, you might want to check well both the treatment of all the accelerations (most codes assume constant translation and/or rotation) as well as the proper treatment of the energy equation.

I am myself now in the process of reviewing the moving frame implementation of my code and I can tell that there is a serious lack of formalism and rigour in most published works. I have found only two completely general treatments (compressible with energy equation and arbitrary motion) and, for example, both completely miss a correct derivation of the continuity equation (yet, as it is left unchanged by a change of frame, they both kind of manage to get the correct result). So, deeply scrutinize whatever source or code you find out there.

[sbaffini]

I took the chance of reviewing my moving frame implementation and it is probably useful to mention here that the only reliable source I could find for the full, compressible, Navier-Stokes equations in an arbitrarily moving reference frame, including the energy equation, is this:

Theoretical treatment of fluid flow for accelerating bodies (2016), by Gledhill et al. (available here)

which is funny, because no previous work seems to get the energy equation correctly, and some even screw up the momentum equation. And because, come on, 2016, really?

[ander]

I had a brief look at the source you posted, it seems very useful. I have only looked at the paper "EULERIAN DERIVATIONS OF NON-INERTIAL
NAVIER-STOKES EQUATIONS" https://www.icas.org/ICAS_ARCHIVE/IC...0577_paper.pdf previously, but it only consider rotations about fixed axes if I'm not mistaken.
I though only the momentum equation would get source terms in the non-inertial frame, but apparently the energy equation also gets source terms which was unknown to me. I will have a closer look at the paper when I have time.

As a sidenote, the article states "The
coupling of time-accurate CFD with rigid body dynamics allows the prediction of trajectories, but
computational resources are not yet sufficient to make this viable for more than fractions of a second", which is perhaps a bit damning for my idea , although the article is 8 years old, and some advancements in computational efficiency may have happened since then.

As when it comes to the implementation my plan has always been to implement the necessary source terms and modify the boundary conditions in an existing code that is originally described in an inertial frame.

The issue with SU2 is that it relies heavily on reference parameters which are supposed to be constant throughout the duration of the simulation (don't know if this is the convention in every CFD code?). Now I'm kind of repeating myself from a previous post, but as an example, the freestream velocity can obviously not be constant in an unsteady trajectory simulation. In fact, I would say that a uniform freestream velocity isn't even a meaningful concept in this case, since the incoming velocity will vary spatially when rotation is present. Can I ask you if you rely on reference values in your CFD implementations?

[sbaffini]

I really wanted to avoid mentioning them and being the usual a..hole, but let me put this straight: what that group has published is utter non-sense and lacks a serious formalism as well as any actual proof. As a result, they come up with a completely random term for the momentum equations (which they call Magnus force). For god's sake, they can't even name the equation terms correctly (using diffusion also for the convective terms), let alone using a consistent nomenclature over the whole paper. If I had to summarize, it would be: trust the swedish people on this matter.

Only for completeness, however, I link here their more complete works on the matter, the ones I actually checked:

http://www.scielo.org.za/pdf/rd/v33/02.pdf
https://nrl.northumbria.ac.uk/id/epr...ytitlenote.pdf

Note that, for all these works, I actually used the official versions from the publisher trough my subscription, I'm posting preprints here because those are the ones available to anyone.

As for the resources, I can't really tell as I am not really into these things (it is just a part of my software suite, but I really don't do these HPC calculations). But I think thst statement might be slightly exaggerated even for 2016, something to write in the introduction just for the sake of it. Maybe it comes from their previous experience back then, which maybe was itself already dated, say, 2006. Of course, this must be considered from the point of view of someone who actually wants to do 6DOF computations of missiles or aircrafts; you should not approach that with a desktop workstation, no matter how big.

I can't really say anything on SU2 neither but, if it is coded in a healthy way, you should be able to set those reference values to unity and treat the code as a dimensional one.

[ander]

That's reassuring to hear, because I remember finding that paper confusing.. They didn't include any magnus forces or diffusive convection terms there, so perhaps not that easy to spot that it was bogus

My plan is to focus on the modelling and implementation for now, and worry about how to actually run stuff later

You are probably right that setting all these values to unity can work. Then physical values would then enter the simulation through initial conditions and boundary conditions. I have heard that one motivation behind nondimensionalizing the equations is that the solver will converge more easily if the nondimentionalized values are close to unity. Not sure if all solvers does this, or how important it is, I guess this will have to be discarded in my case anyhow.

[sbaffini]

Originally Posted by ander

That's reassuring to hear, because I remember finding that paper confusing.. They didn't include any magnus forces or diffusive convection terms there, so perhaps not that easy to spot that it was bogus

I actually didn't follow the whole paper, but one way to tell it is bogus is that such Magnus term involves the cross product between the two components of the relative velocity. In order for such a term to appear you necessarily need in the original Navier Stokes equations a term involving the cross product of the velocity with itself. But it doesn't of course, because that would be 0 in any case. It is even hard to follow what they mean for V(t) in such term, as that gets mixed with Vrel in an unhealthy way. At least they mention they were unsure about including it.

Originally Posted by ander

I have heard that one motivation behind nondimensionalizing the equations is that the solver will converge more easily if the nondimentionalized values are close to unity. Not sure if all solvers does this, or how important it is, I guess this will have to be discarded in my case anyhow.

This matter frequently resurrects here. One reason to have nondimensonal equations is that it can kind of help with single precision solvers. In that case you do the arithmetic with variables which, presumably, are all at most O(1). But for double precision I see this as a non issue. Another argument is that having nondimensional variables helps checking for correctness as everything is expected to be O(1) but, again, I find this very aneddotical, as I can't rely on such sort of things to properly debug a code. Finally, someone also mentioned me that for the English world, working mostly with non SI units, that might actually help.

From my perspective of code developer and maintainer, having nondimensional numbers around is just another complication that I don't want. The only thing I do for numerical precision, even if always using double, is to use gauge pressure and temperature in my calculations. It costs me nothing and is well hidden in the code and it really gives you better convergence (but it actually means that you get better precision).

[ander]

That's reassuring, I feared that it was somehow necessary to use nondimensionalization to reach convergence. Not that I have much experience with working with CFD codes, but to me this also seems like something that complicates things more than it helps. Hopefully I'm able to work around it with regards to SU2.

I guess your last point about using gauge values only applies to certain calculations. For instance, if you calculate the resultant force around a body you would be fine by using the gauge pressure. But something like evaluating the speed of sound for an ideal gas as c = \sqrt(\gamma p/\rho) would require the absolute pressure.

[sbaffini]

Originally Posted by ander

I guess your last point about using gauge values only applies to certain calculations. For instance, if you calculate the resultant force around a body you would be fine by using the gauge pressure. But something like evaluating the speed of sound for an ideal gas as c = \sqrt(\gamma p/\rho) would require the absolute pressure.

Yes indeed, that's an important aspect of using gauge values and what I referred to when I mentioned that it is well hidden in the code. All my thermodynamic calculations, which are the only ones needing absolute values, properly add and subtract reference values when doing their calculations.

Note that, typically, there are also other components to be added/removed for the pressure in a general code, depending from the implementation. Indeed, one of them in my code is the centrifugal apparent force evaluated for a reference density, which can be expressed as the gradient of a scalar which is then subtracted from the pressure

[ander]

I have now attempted to add linear acceleration functionality to the SU2 code. This is done by making the free stream velocity used by the far field BC the opposite value of the reference system velocity and adding source terms to the energy and momentum equations.
To test the correctness of the implementation, I ran a simulation of a constantly accelerating system in an empty domain and initially still air, and plotted the mach number along x-axis (which is aligned with the acceleration vector). What I want to see is a mach number distribution that has no gradients in the x direction and that increases linearly in time (corresponding to the rigid body motion of the fluid seen from the accelerating frame).

I used the following source term for the momentum equation (adopting the notation from the article http://researchspace.csir.co.za/dspa...1&isAllowed=y: )

momentum equation: .
( and are the velocity and acceleration of the non-inertial frame, respectively.)

However, the treatment of the energy equation is a little unclear to me. In equation (46) of the article, the suggested linear motion terms are , while in equation (59) these terms read
.

I have tested various versions, and only when I completely omit the term do I get the desired "rigid body motion" that I sought. In this case I get this correct motion. I tested this by starting at some supersonic initial freestream condition before decelerating below subsonic. It worked very well in this case.

My question now is whether I have done something wrong, or if the mentioned paper is not completely to be trusted. The paper also uses the term "rothalphy" for the energy in the non-inertial frame, but looking at the equation, the left hand side terms are identical to the standard energy equation (except that it is formulated in the non-inertial frame). For this reason I believe that only the source terms of the energy equation in SU2 need modification (no modification of convective terms).

I guess I will have to investigate further by looking at more sources if they exist.

[sbaffini]

Originally Posted by ander

I have now attempted to add linear acceleration functionality to the SU2 code. This is done by making the free stream velocity used by the far field BC the opposite value of the reference system velocity and adding source terms to the energy and momentum equations.
To test the correctness of the implementation, I ran a simulation of a constantly accelerating system in an empty domain and initially still air, and plotted the mach number along x-axis (which is aligned with the acceleration vector). What I want to see is a mach number distribution that has no gradients in the x direction and that increases linearly in time (corresponding to the rigid body motion of the fluid seen from the accelerating frame).

I used the following source term for the momentum equation (adopting the notation from the article http://researchspace.csir.co.za/dspa...1&isAllowed=y: )

momentum equation: .
( and are the velocity and acceleration of the non-inertial frame, respectively.)

However, the treatment of the energy equation is a little unclear to me. In equation (46) of the article, the suggested linear motion terms are , while in equation (59) these terms read
.

I have tested various versions, and only when I completely omit the term do I get the desired "rigid body motion" that I sought. In this case I get this correct motion. I tested this by starting at some supersonic initial freestream condition before decelerating below subsonic. It worked very well in this case.

My question now is whether I have done something wrong, or if the mentioned paper is not completely to be trusted. The paper also uses the term "rothalphy" for the energy in the non-inertial frame, but looking at the equation, the left hand side terms are identical to the standard energy equation (except that it is formulated in the non-inertial frame). For this reason I believe that only the source terms of the energy equation in SU2 need modification (no modification of convective terms).

I guess I will have to investigate further by looking at more sources if they exist.

I have to be honest here and say that I've been a little bit superficial. When I suggested the Gledhill paper, I did it without having myself tested it, as my code doesn't really have accelerations beside constant rotation. What I had checked were the equations but, again, I was a little bit superficial, as I only checked them up to equation 45 and first equality of equation 46.

However, what I have now found (but I haven't still written about it here as I am in the process of double checking it) is that everything beyond that point doesn't correspond anymore to what I found. Note, in particular, that in the official published paper, equation 43, the definition of rothalpy and relative energy, comes later and on a different page, and that I have a mismatch also on its definition (the second equality). The other mismatch I have is on the expansion of u underscore dot. In practice, I followed the paper up to a certain point and then just dropped it as I considered the rest just obvious substitutions (and I was, in theory, checking me and my equations, not the paper ones).

So, with this premise, I can't tell you if that term is correct as I never got to have the same equations in the end. I can only tell you that all the equations in the openly available paper correspond to the ones in the official published paper.

However, as I still doubt some of my equations, I tend to believe that the Gledhill paper is correct. Also, I have checked most other sources, and they are either provably wrong in at least some other part of their derivation or, for the energy equation, just take the scalar product of the apparent forces with the relative velocity, which is a completely unjustified approach, in my opinion.

May I ask if you saw differences only for energy or something else? And what is that you expect to see for the energy? Said otherwise, how could you tell that neglecting the term gives correct results?

The point here is that their equation is an equation for E* so, assuming their equations are correct, if all the terms in your implementation correspond, the energy variable you are solving for is, indeed, E*. Now, the trouble comes in understanding how SU2 actually handles the variable that it solves for the energy. It should be treating it as E* just as defined in the paper, otherwise it will give uncorrect result. This, in turn, depends from how SU2 solves the equations. In my solver, for example, that definition of E* only comes out in the convective term, where I need to build H from its components. But if SU2 uses a different definitions of E* with respect to the equation you are using as reference, than you have different results.

Anyway, let me know if you can find additional trustable sources on the matter. I'll keep you updated on this as well. I actually already asked the authors about a possible typo in the definition of E*. Either way, their answer will give me indications on where to look next.

[ander]

I will try to explain my idea for verifying the implementations more clearly. The idea is to consider an empty control volume (connected to a non-inertial frame) moving through an inertial frame. The inertial frame has still fluid (the velocity of the inertial field and constant density and pressure. The empty non inertial-frame control volume is the simulation domain (which means that I have created a mesh with far-field boundaries and no internal geometry) . If the control volume has no rotations and a velocity , we would expect to see a solution inside the domain , i.e a velocity field with no spatial gradients that increases linearly with time. The density and pressure should remain unchanged since these are invariant to transformations between frames.

I only managed to get such a solution when I neglected the term in the energy equation. When I included this term, the velocity field formed gradients in the x-direction. Note that I haven’t checked the solution of the energy field itself, I have only considered the velocity field to check whether the solution seems correct, but an incorrect definition of the energy equation would surely mess up the velocity field. However, a more thorough verification is definitely needed.

When it comes to the energy equation in SU2, I have checked that it is on the same form as the rothalpy equation, except for the source terms: https://su2code.github.io/docs_v7/Theory/. (I have also partly verified that this definition of the energy is actually used inside the code, and not only in the documentation). For this reason, I believe that the energy equation in SU2 only need the additional source terms from equation (46) to correctly represent the rothalpy equation.

Going forward, I think I will try to gain a better understanding of the Gledhill paper and try to implement and test some more terms (like constant rotation). I will keep you updated through this thread, and would definitely hear what the authors of the Gledhill paper have to say about the rotalphy equation.