Feasibility of modeling trajectories of projectiles using moving reference frame

ander · November 25, 2022, 13:45

I know realize a mistake I've made (probably what you pointed out earlier), I will have to modify the SU2 functions that converts energy to pressure (or other thermodynamic quantities), so that they correspond to the rothalpy equation....

sbaffini · November 25, 2022, 16:06

Quote:

Originally Posted by ander

I know realize a mistake I've made (probably what you pointed out earlier), I will have to modify the SU2 functions that converts energy to pressure (or other thermodynamic quantities), so that they correspond to the rothalpy equation....

Exactly. It depends from which variables SU2 uses as independent but, at a certain point, it is going to need other variables that will inevitably involve the rothalpy definition.

In my code I solve for the temperature and I only need the rothalpy definition for building the convective term in the energy equation. But other combinations are possible.

Obviously, all of this holds if SU2 actually solves the equations for the relative velocity, otherwise things might be even more complicated. But if it is well designed, it should have a single code line where that definition is invoked and everything else depend on that line.

ander · November 27, 2022, 17:52

I have revised my implementation now, and tested it for linear motion. In all relevant lines where it was written E = e + 0.5*||v||^2 or e = E - 0.5*||v||^2, I modified the code (this was about 5 places in total), 2 for the solution initialization, 2 for the calculation of primitive variables during solving and 1 for the far field BC.

I guess that since density, pressure, temperature and static energy are invariant to motion of the frame, these redefinitions should be sufficient.

The rightmost expression in equation (43) seems to be wrong, if I'm not mistaken it should be E* = e + 0.5(||v||^2 - ||u||^2). Using this definition also gave me seemingly correct results in my 1D linear acceleration test, but better testing is definitely needed to be sure.

sbaffini · November 27, 2022, 19:17

Quote:

Originally Posted by ander

I have revised my implementation now, and tested it for linear motion. In all relevant lines where it was written E = e + 0.5*||v||^2 or e = E - 0.5*||v||^2, I modified the code (this was about 5 places in total), 2 for the solution initialization, 2 for the calculation of primitive variables during solving and 1 for the far field BC.

I guess that since density, pressure, temperature and static energy are invariant to motion of the frame, these redefinitions should be sufficient.

The rightmost expression in equation (43) seems to be wrong, if I'm not mistaken it should be E* = e + 0.5(||v||^2 - ||u||^2). Using this definition also gave me seemingly correct results in my 1D linear acceleration test, but better testing is definitely needed to be sure.

I'm also pretty confident that there is a typo in the second equality of eq. 43, which should be as you suggest. I asked the authors on researchgate but I still haven't had an answer.

sbaffini · December 2, 2022, 03:44

Quote:

Originally Posted by sbaffini

I'm also pretty confident that there is a typo in the second equality of eq. 43, which should be as you suggest. I asked the authors on researchgate but I still haven't had an answer.

I've had now a confirmation that there was, indeed, a typo in Eq. 43, which should have a minus sign for the squared magnitude of the ref. frame velocity. Actually, only now I have found this other work from the same group which, in the appendix, has the correct equation.

I'll keep you informed as soon as I can re-check my math for the last part of the paper.

ander · December 5, 2022, 18:54

There are definitely more equations in the paper that don't add up. Some of these seem to just be typos that have been corrected at the next equation. There is also another category of equations. Here I'm not really sure if the equations are wrong or if I don't understand them properly.
Equations that I have looked at and find fishy include:

equation (11): $\dot{r}$ should be $\breve{\dot{r}}$ and should be $\underbar{x}$
equation (13): This one is important to get right for my own implementation since it appears in the final equation for rothalpy. The inteframe velocity equals $\underbar{u} = \breve{\dot{r}} + \breve{\omega}\times\underbar{x}$ . Then why shouldn't its time derivative become $\dot{\underbar{u}} = \dot{\breve{\dot{r}}} + \breve{\dot{\omega}}\times\underbar{x} + \breve{\omega}\times\underbar{v}$ , i.e. applying the product rule to the cross product?
The mappings defined in the beginning of section 3.3 makes little sense to me. For instance it's written $r+ U\cdot x$ one place, which is an attempt to add two vectors living in different frames.. But perhaps I'm missing something...
equation (23): It seems like the general conservation law given by equation (15) is not used when applied to the momentum equation given by eq. (23). To be consistent with equation (15), I believe the outer product should read $v \otimes \hat{\underbar{v}}$ instead of $v \otimes v$
equation (59): I've mentioned this one before. The term proportional to $\rho\underbar{v}\dot{\breve{\dot{r}}}$ in equation (59) is inconsistent with the same term in equation (46), Equation (46) (which is the more fundamental equation) seems to have the correct factor, based on a (1D energy of point mass check I did)

I have a feeling that the guy who derived these equations have not been directly involved in writing the paper..

duongvps · December 6, 2022, 01:24

https://daututudau.net/

sbaffini · December 6, 2022, 07:04

Quote:

Originally Posted by ander

There are definitely more equations in the paper that don't add up. Some of these seem to just be typos that have been corrected at the next equation. There is also another category of equations. Here I'm not really sure if the equations are wrong or if I don't understand them properly.
Equations that I have looked at and find fishy include:

equation (11): $\dot{r}$ should be $\breve{\dot{r}}$ and should be $\underbar{x}$
equation (13): This one is important to get right for my own implementation since it appears in the final equation for rothalpy. The inteframe velocity equals $\underbar{u} = \breve{\dot{r}} + \breve{\omega}\times\underbar{x}$ . Then why shouldn't its time derivative become $\dot{\underbar{u}} = \dot{\breve{\dot{r}}} + \breve{\dot{\omega}}\times\underbar{x} + \breve{\omega}\times\underbar{v}$ , i.e. applying the product rule to the cross product?
The mappings defined in the beginning of section 3.3 makes little sense to me. For instance it's written $r+ U\cdot x$ one place, which is an attempt to add two vectors living in different frames.. But perhaps I'm missing something...
equation (23): It seems like the general conservation law given by equation (15) is not used when applied to the momentum equation given by eq. (23). To be consistent with equation (15), I believe the outer product should read $v \otimes \hat{\underbar{v}}$ instead of $v \otimes v$
equation (59): I've mentioned this one before. The term proportional to $\rho\underbar{v}\dot{\breve{\dot{r}}}$ in equation (59) is inconsistent with the same term in equation (46), Equation (46) (which is the more fundamental equation) seems to have the correct factor, based on a (1D energy of point mass check I did)

I have a feeling that the guy who derived these equations have not been directly involved in writing the paper..

Let me again clarify that when I delved into this, I didn't actually follow the paper derivations but I wanted to check my own implementation and derivation.

The way I derived the equations was based on deriving the expressions for the change of frame for scalars, position vector, velocity vector and, finally, the spatial and temporal derivative (that is, how are the original derivatives expressed in terms of relative frame quantities?). Then I just made a term by term substitution and simplification. I went my own route and checked the paper on some equations which, at the beginning, were just the end ones as I was checking me and not the paper.

Note that, for example, I never drop the matrix U in my derivations in favor of a more clumsy notation. I always have U or Ut in place, so that it is impossible for me to be unsure on what is what. So, I had a full check on equations 1 to 10, but never actually looked at 11 as for me was just the same equation as 10 premultiplied with Ut and rearranged, I didn't have doubts on that. Still, you seem correct in questioning it. 14 just pops out here and there in my derivations, actually in a more general form, but it is correct.

Then, again, I only checked 22 for continuity (where I can grasp the reason it follows from 21 but didn't really follow the derivation in 15-19) and 26-27 for the momentum (yet I didn't even look at 23-25, as they looked unreasonably complex for what I needed). They all checked positively with my own equations.

For energy, I had myself a wrong implementation for sure, so I really wanted to check this. I went my own way and later checked that I had agreement with 45. Then, I took for granted their 46 and just used that. Which in my steady translation/rotation case just meant that I dropped everything on the RHS except the gravity and energy source term. Seemed correct to me.

When you wrote here for the first time, this was my experience with this paper. And let me say that this is still the only paper that doesn't make any absurd step in its energy equation derivation. This was the only one I had a positive check with.

Then, I rechecked the energy equation and two things popped out:

1 - My equivalent of eq. 32 doesn't have $\underline{\mathbf{u}}$ but $\mathbf{u}$ , which means that I then do a scalar product with the momentum eq. still expressed in the inertial frame. This of course doesn't make any real difference for the scalar product (as keeping U and Ut around would have clarified).

2 - The typo in eq. 43

All in all then, typo in 43 apart, I could still confirm a match with eq. 45. However, because of the typo, I decided to also go from 45 to 46 and I agree with you, as I also don't have a match with their time derivative of $\underline{\mathbf{u}}$ . That is, 13 is wrong to me as well. I think so because I need a different differentiation of it in order to get the momentum right.

However, I stopped there and I still have doubts because from my derivation of 46 new terms come out that would be present also in steady mode and are in contrast to any other dierivation I have seen for that case. These terms are exactly those linked to the missing terms in 13. I wanted to recheck again, but then time run out quickly and this is currently on hold.

In the end, I can confirm 22, 27 and 45, with 43 a confirmed typo from the authors. I can't confirm 46 because I suspect an error in 13 as well and I started a completely different derivation to check, but I am still working on it. Still, I'm not yet 100% sure about 13 being wrong as I was for 43.

ander · December 9, 2022, 10:34

Ok nice!
Then I guess if you're quite sure about equation (45), equation (13) is the equation with the largest impact of the actual code among the uncertain equations.

It seems like that the guy behind the equations is working for the Swedish military, that likely explains why it is hard to get a hold of the original derivations

I have taken a look at some other papers.
I guess this one: https://www.politesi.polimi.it/bitst...I_corretta.pdf
is among one of these that assumes that the energy source terms can be found by simply dotting the non-inertial velocity vector with the fictitious forces.

I also set up a simple pure rotation case in a disk shaped domain with my code. I discovered that the solution fails when the rotation speeds gets too high, but I guess this has to be expected. From my experimentation it seems that reducing the timestep doesn't help much. I'm not familiar with the stability analysis of source terms, or techniques to allow larger source term magnitudes.

For an ideal implementation it would perhaps be nice to have a small spherical non-inertial domain around the geometry while the surrounding domain would also be a non-inertial frame, but only undergoing translational motion. The smaller domain would decrease source terms dependent on the radius. If I understand it correctly the interpolation required to achieve this is known as Arbitrary Mesh Interface (AMI). Apparently SU2 doesn't have this implemented, but OpenFOAM has..

sbaffini · December 9, 2022, 11:51

Quote:

Originally Posted by ander

Ok nice!
Then I guess if you're quite sure about equation (45), equation (13) is the equation with the largest impact of the actual code among the uncertain equations.

It seems like that the guy behind the equations is working for the Swedish military, that likely explains why it is hard to get a hold of the original derivations

I have taken a look at some other papers.
I guess this one: https://www.politesi.polimi.it/bitst...I_corretta.pdf
is among one of these that assumes that the energy source terms can be found by simply dotting the non-inertial velocity vector with the fictitious forces.

I also set up a simple pure rotation case in a disk shaped domain with my code. I discovered that the solution fails when the rotation speeds gets too high, but I guess this has to be expected. From my experimentation it seems that reducing the timestep doesn't help much. I'm not familiar with the stability analysis of source terms, or techniques to allow larger source term magnitudes.

For an ideal implementation it would perhaps be nice to have a small spherical non-inertial domain around the geometry while the surrounding domain would also be a non-inertial frame, but only undergoing translational motion. The smaller domain would decrease source terms dependent on the radius. If I understand it correctly the interpolation required to achieve this is known as Arbitrary Mesh Interface (AMI). Apparently SU2 doesn't have this implemented, but OpenFOAM has..

Yeah, I don't know if I would bring a mesh interface just for that. I don't know how OF handles that, but if that implies abandoning conervation, I don't know if I would take it.

Ideally, using an absolute velocity formulation actually reduces the source term to a half Coriolis-like term. But the relative velocity formulation can also be casted in such a way to absorb a constant density centrifugal term in the pressure, which means that the actual difference is just a factor of two in front of Coriolis plus a deviation from constant density times the centrifugal term.

I guess you don't have alternatives for the code, like, say, Fluent or CFX?

Equation 13 is, indeed, where I'm stuck now. I have $-\rho \mathbf{u} \dot{\mathbf{u}}$ as source term for the energy equation written in terms of relative velocity and relative energy/rothalpy. If I apply eq. 13 I agree, of course, with eq. 46, but I don't agree on 13 as of now.

I will probably write again to the authors, maybe this time asking for some support material.

The people at FOI are indeed pretty well known in the CFD field. Yet, it is weird that they didn't, as well, publish any of this before .

December 5, 2022, 18:54		#26
ander Member Anders Aamodt Resell Join Date: Dec 2021 Location: Oslo, Norway Posts: 64 Rep Power: 4	There are definitely more equations in the paper that don't add up. Some of these seem to just be typos that have been corrected at the next equation. There is also another category of equations. Here I'm not really sure if the equations are wrong or if I don't understand them properly. Equations that I have looked at and find fishy include: equation (11): $\dot{r}$ should be $\breve{\dot{r}}$ and should be $\underbar{x}$ equation (13): This one is important to get right for my own implementation since it appears in the final equation for rothalpy. The inteframe velocity equals $\underbar{u} = \breve{\dot{r}} + \breve{\omega}\times\underbar{x}$ . Then why shouldn't its time derivative become $\dot{\underbar{u}} = \dot{\breve{\dot{r}}} + \breve{\dot{\omega}}\times\underbar{x} + \breve{\omega}\times\underbar{v}$ , i.e. applying the product rule to the cross product? The mappings defined in the beginning of section 3.3 makes little sense to me. For instance it's written $r+ U\cdot x$ one place, which is an attempt to add two vectors living in different frames.. But perhaps I'm missing something... equation (23): It seems like the general conservation law given by equation (15) is not used when applied to the momentum equation given by eq. (23). To be consistent with equation (15), I believe the outer product should read $v \otimes \hat{\underbar{v}}$ instead of $v \otimes v$ equation (59): I've mentioned this one before. The term proportional to $\rho\underbar{v}\dot{\breve{\dot{r}}}$ in equation (59) is inconsistent with the same term in equation (46), Equation (46) (which is the more fundamental equation) seems to have the correct factor, based on a (1D energy of point mass check I did) I have a feeling that the guy who derived these equations have not been directly involved in writing the paper..

December 6, 2022, 01:24	hihi	#27
duongvps New Member viet nam Join Date: Dec 2022 Posts: 1 Rep Power: 0	https://daututudau.net/

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Post processing of rotational moving reference frame	Brathmann	FLUENT	1	March 22, 2013 10:39
moving mesh vs moving reference frame	nikolaous	FLUENT	0	August 1, 2012 18:46
G95 + CGNS	Bruno	Main CFD Forum	1	January 30, 2007 00:34
Building OpenFoAm on SGI Altix 64bits	anne	OpenFOAM Installation	8	June 15, 2006 09:27
Windows Installation BugsComments on Petrbs patch	brooksmoses	OpenFOAM Installation	48	April 16, 2006 00:20

November 25, 2022, 13:45		#21
ander Member Anders Aamodt Resell Join Date: Dec 2021 Location: Oslo, Norway Posts: 64 Rep Power: 4	I know realize a mistake I've made (probably what you pointed out earlier), I will have to modify the SU2 functions that converts energy to pressure (or other thermodynamic quantities), so that they correspond to the rothalpy equation....

November 27, 2022, 17:52		#23
ander Member Anders Aamodt Resell Join Date: Dec 2021 Location: Oslo, Norway Posts: 64 Rep Power: 4	I have revised my implementation now, and tested it for linear motion. In all relevant lines where it was written E = e + 0.5\|\|v\|\|^2 or e = E - 0.5\|\|v\|\|^2, I modified the code (this was about 5 places in total), 2 for the solution initialization, 2 for the calculation of primitive variables during solving and 1 for the far field BC. I guess that since density, pressure, temperature and static energy are invariant to motion of the frame, these redefinitions should be sufficient. The rightmost expression in equation (43) seems to be wrong, if I'm not mistaken it should be E* = e + 0.5(\|\|v\|\|^2 - \|\|u\|\|^2). Using this definition also gave me seemingly correct results in my 1D linear acceleration test, but better testing is definitely needed to be sure.

December 9, 2022, 10:34		#29
ander Member Anders Aamodt Resell Join Date: Dec 2021 Location: Oslo, Norway Posts: 64 Rep Power: 4	Ok nice! Then I guess if you're quite sure about equation (45), equation (13) is the equation with the largest impact of the actual code among the uncertain equations. It seems like that the guy behind the equations is working for the Swedish military, that likely explains why it is hard to get a hold of the original derivations I have taken a look at some other papers. I guess this one: https://www.politesi.polimi.it/bitst...I_corretta.pdf is among one of these that assumes that the energy source terms can be found by simply dotting the non-inertial velocity vector with the fictitious forces. I also set up a simple pure rotation case in a disk shaped domain with my code. I discovered that the solution fails when the rotation speeds gets too high, but I guess this has to be expected. From my experimentation it seems that reducing the timestep doesn't help much. I'm not familiar with the stability analysis of source terms, or techniques to allow larger source term magnitudes. For an ideal implementation it would perhaps be nice to have a small spherical non-inertial domain around the geometry while the surrounding domain would also be a non-inertial frame, but only undergoing translational motion. The smaller domain would decrease source terms dependent on the radius. If I understand it correctly the interpolation required to achieve this is known as Arbitrary Mesh Interface (AMI). Apparently SU2 doesn't have this implemented, but OpenFOAM has..