Errors in low-pressure compressible flow (Hyperloop)


#1

I’m trying to calculate drag at low ambient pressure, but getting errors in the pressures.
https://www.simscale.com/projects/RichMacf/test_disc/

This is a simplification of my Hyperloop project, to find the drag of a pod at high speed and vacuum.
https://www.simscale.com/projects/RichMacf/hyperloop_pod_in_tube/
Hyperloop runs up to 250 m/s in a tube lower than 1kPa absolute pressure. So I guess the simulation must be compressible, I was getting good flow pictures, but absurd drag figures.

In the test disc project, I have checked the pressure and drag force on a simple disc. At atmospheric pressure, compressible and incompressible gave similar results. But at 1 kPa absolute, the compressible drag only reduced by half, while the incompressible reduced by 100X, as expected. In each case the drag force from results was consistent with the pressures shown in the coloured image. So the pressures in the compressible simulation are way out.

I’ve been to find the best compressible model. The default settings failed (too many iterations) with any speed. So I’ve copied all the parameters from Ali’s Airliner project, and managed to get up to 30 m/s. But I would like 200 m/s if possible.

Thanks for your help


#2

Hi @RichMacf!

Maybe our @PowerUsers_CFD can give you some tips here. I will have a look at your project as soon as I have access to a machine :slight_smile:

All the best!

Jousef


#3

Hi @RichMacf,

Nice to see the simulation of the HyperLoop starting up! You’ll have to forgive me for some probably large theoretical errors regarding any incoming questions I’m asking in an attempt to solve your issues, so here goes.

I was wondering about compressible flow and this got me thinking about mach numbers. So speed of object is fixed at 200m/s. Inside the tube however, what would be the speed of sound and as a result the resulting mach number? From there I think we can kind of guess how much compressibility is a factor.

I’m currently running your simulation to see what I can figure out. So I’ll let you know if I can get anything. So far, a steady-state compressible flow simulation shouldn’t be too problematic since its not very complex. Oh and last thing you do need more iterations for your simulation runs as you can see a steady-state hasn’t been reach yet for some of the simulations so do set a slightly longer end time.

Cheers!

Regards,
Barry


#4

Hi Barry,

Thanks for thinking about the Mach numbers, Hyperloop is an interesting flow situation with no precedent.

At low speeds, incompressible, the backflow thru the throat equals the pod speed (in my 2:1 tube pod area ratio), so the airflow over the pod is doubled due to the tube. But as we increase speed, the flow relative to the pod will approach Mach 1, and may become choked like an orifice.

If the backflow can’t increase in speed, it must compress to allow the required mass flow. The whole challenge of the project, is to see the flow and measure the drag when the pod speed (>150 m/s) forces the air in the throat to be compressed up to 2:1, and up to Mach 1.

Just a quick question about the number of iterations. I can see the convergence lines not really settled, but the force results are straight lines from quite early in the calculations. Would more iterations help?


#5

Hi @RichMacf,

I’ve just run a quick 200m/s inlet run and yes the values are very off with absurd coeff of drag (Cd) of 70 plus at peak and some strange oscillation with the flow. I’ll keep looking into what the issue could be but do you have a rough gauge of what the Cd should be around?

Ah I see so the compressible effect comes from the chocked flow. I was thinking in terms of mach no but I realize that is not really applicable here, too much high speed aerodynamics classes :stuck_out_tongue:

That won’t get your values to be “realistic” as they are way off at the moment, however when we’ve finally sorted out the issue with the values, ensuring convergence is met via a criteria of some sorta and at steady-state would ensure your obtainment of the most accurate results.

Cheers!

Regards,
Barry


#6

hi @Get_Barried,

Looking at drag coefficients. Using the drag forces at atmospheric pressure, which seem reliable, we get a Cd (frontal area) of 0.65. I have created a Throat Speed Factor, Tsf, which is the speed in the throat due to the tube interference. For our geometry the Tsf is 2, so we can divide this measured Cd by Tsf^2 because of the increased airspeed.

So the Cd becomes 0.65 / 4 = 0.16. This seems reasonable, the pod is a streamlined clean shape, but quite long.

This should be reasonable calculation for slow speeds, but we would expect a sharp increase in Cd as the flow becomes choked (or whatever happens) in the throat.


#7

Hi @RichMacf,

Great insight into the methodology towards deducing the Cd. So far I’ve obtained absurd values where Cd is over 20 and peaks at 70 so there are several issues to solve. Again, I will be running the simulations to try to obtain something within margin and will let you know if I do get something close.

If you manage to make some do let me know so I can incorporate it towards achieving the expected results!

Cheers.

Regards,
Barry


#8

Hi @Get_Barried

Just a thought. At the 100Pa level, the pressure differences are so high that the low absolute pressure becomes negative. I can’t see how any computations can cope with zero or -ve absolute pressure. So the absolute pressures that we are entering for compressible flow, could be converted to relative somewhere.

Cheers, Richard


#9

Hi Richard,

Interesting predicament. Will take note of it. Thanks for the heads up!

Cheers.

Regards,
Barry


#10

Hi Richard,

No luck on my end, seems like I keep obtaining rather absurd values. I might re-mesh but was wondering if you’ve made any breakthroughs?

Cheers.

Regards,
Barry


#11

Thanks @Get_Barried for your help.

No, I can’t do much. There are not many projects with high speed, and I’ve tried their settings. Hyperloop is quite extreme, and it gets beyond the normal tested environment.

There are so many settings and parameters, I have no idea of how to start! I’ve contacted Support to see if there’s a solution.


#12

Hi @RichMacf!

I would like to give your simulation a try later on when I have a bit more time if that’s okay. I think you do not want to have the results immediately, do you? :wink: Already gathered some good ideas and approaches also considering physical effects like the Kantrowitz limit we have to think about if our tunnel diameter is not super big. Have you already done some research in this direction? :thinking:

Cheers!

Jousef


#13

Hi @jousefm and @Get_Barried,

Would love to have your help. Hyperloop is getting more media attention, and it could be good PR for SimScale if the high-speed flow problems can be explained.

The ‘Kantrowitz Limit’ was proposed in Elon Musk’s original proposal, about page 5 http://www.spacex.com/sites/spacex/files/hyperloop_alpha-20130812.pdf

He correctly stated that flow thru an orifice can never exceed Mach1, then used the incompressible calculations of back-flow to propose the “Kantrowitz Limit” which no pod could exceed. He then proposed a large compressor to divert most of the frontal airflow thru a small duct to the tail. Kantrowitz has dominated Hyperloop aerodynamic theory, and most designs show some form of compressor, although the idea is losing support.

In my (totally unqualified) opinion, the Kantrowitz Limit is wrong, and it’s an absurd solution to have a complex compressor with a 20:1 ratio forcing air thru a small duct. It’s wrong to apply incompressible theory to a high-speed situation. Compression is required, but only 2:1 in the throat using the thrust of the wheels or linear motors.

At a pod speed of Mach 0.5, the back flow (with my 2:1 area ratio) is also M0.5. If we only consider incompressible, we than have an airflow of M 1.0 vs the pod, and M 0.5 vs the tube. So its not really like a choked orifice.

But we must consider compressible flow. At a pod speed of Mach 1 (our max is about M 0.7), the flow in the orifice would be a simple outward compression of about 2:1. There would be shock waves and increased drag, but acceptable with very low pressure in the tube.

Hyperloop is a really fascinating airflow situation, with high speed in a confined tube. It would be great if SimScale could do the simulations, it would contribute to the future of high-speed transportation!


#14

Hi Richard,

Interesting insight, I’ll have to read more into it. So far the simulations have been uncooperative to put it nicely and I suspect it may just be some settings. Also of note SimScale runs OpenFOAM older versions and the new versions may have some tools we can use towards this. As such, I’ve elected to get the latest version of OpenFOAM (5.0) on my computer to see if we can get it running although no promises on when that can be done as I’m quite limited on time.

I do suggest you can take a similar approach and maybe try OpenFOAM on your computer or another CFD software like Ansys or StarCCM+ if you access to them. I’ll keep tacking both sides and running on SimScale and locally on my computer so if I get anything I’ll let you know.

I do need to do some read-up on what you’ve talked about and its has certainly peaked my interest if anything. Lets converse more and work on this.

Cheers!

Regards,
Barry


#15

New paper on this topic: https://www.researchgate.net/publication/326736828_Aerodynamic_Design_of_the_Hyperloop_Concept

Barry (@Get_Barried): We need to try some runs on that one :sunglasses:

Cheers,

Jousef


#16

Hey Jousef,

Good stuff! Compressible flow might still be an issue. Maybe time to revive the diamond aerofoil project again then move on to this?

Cheers.

Regards,
Barry


#17

Hi everyone,

While I’m still wrapping up another compressible flow project, I was doing some research on the solver used for this simulation. From what I’ve gathered, the solver we are using (rhoSimpleFoam) does not work for transonic steady-flows. Why this is the case I am not too sure, but I’ve read that it might have to do with the fact that rhoSimpleFoam is an uncoupled solver and this means that at transonic to supersonic flow, the solution will be unable to converge regardless of numerical dampening.

The recommended course correction would be to use a transient solver, namely rhoCentralFoam. However, turbulence effects will be negated as rhoCentralFoam is laminar. As for rhoPimpleFoam which is a transient solver with turbulence, I have not investigated the usage of it for transonic/supersonic flow.

Obviously, usage of a transient solver will result in less efficient solving due to the small timesteps involved and the need to adhere to courant numbers of less than 1. In addition, if one wants to use fine grids, like in this case (in order to determine the drag on the pod) then the computational cost increase will be substantial.

Sounds good, so all I have to do is change solver and just run a transient simulation? Well I would do so, but there several things I still don’t understand and maybe someone can enlighten me.

  • If rhoSimpleFoam is unable to converge for transient/supersonic flows, then why is this paper able to do so? I suspect that they coupled their own formula’s to the rhoSimpleFoam to allow steady-state convergence, but it isn’t clear to me. Can anyone confirm?
  • What does the transonic option in the numerics do? Provide a coupled equation?
  • What is the difference between a pressure-based and density-based solver? It seems like for high mach no flows, pressure-based solvers do not converge well for some reason. Is this observation even correct?
  • The usage of implicit and explicit schemes in this context, along with how they are expected to behave. I am unable to understand the implications of the usage of either methods. Generally it seems that implicit schemes are better for compressible flows, but why?

So many questions and no real answers as the documentation relating to transonic/supersonic flow beyond very basic 2D geometries is very limited. Even more limited is documentation for steady-state solutions for such high speed flows.

For everyone’s reference, here is the list of solvers

image

Back to more head cracking.

Cheers.

Regards,
Barry


#18

Hi Barry,

nice research you have done there! Let me tag @sjoshi and @dzivkovic who might give you more information about the implementation.

Cheers,

Jousef