[mavguy]

I would like to introduce a solver I have been working on, free for non-commercial use. It can be found at http://www.flowedg.com .

Currently, it's capabilities are limited, but are being actively developed and expanded.

If you have any questions, please don't hesitate to ask!

[arjun]

Originally Posted by mavguy

I would like to introduce a solver I have been working on, free for non-commercial use. It can be found at http://www.flowedg.com .

Currently, it's capabilities are limited, but are being actively developed and expanded.

If you have any questions, please don't hesitate to ask!

"

• Memory requirement is quite high, particularly in 3D (60GB per 1 million p=2 tetrahedra)
  "

What is the reason for it. Is it because of direct solver being used??

[mavguy]

Hi arjun,

No, the linear solver is not a direct solver-- if it were, the memory requirement would be enormous. It uses GMRES for the linear system solve, like most other 3D solvers out there.

The reason is the nature of the DG method itself. Most of the DG solvers out there are explicit (i.e. don't solve a linearised system of equations) and thus they only need to store the residual. However, for implicit methods you need to store the Jacobian. For the regular DG method, the number of non-zeros in the Jacobian scales as O(p^6), while the HDG and EDG methods scale as O(p^4) in 3D.

The advantage of using EDG over HDG is that the coefficient dictating number of non-zeros in the Jacobian is much smaller than that of HDG, at least up to p=5 in 3D. Of course, the amount of time it takes to solve the linear system is directly proportional to the number of non-zeros in the Jacobian. For example with p=3 in 3D, EDG has 1000 blocks of non-zeros for every mesh vertex, while the regular DG method will have 10,000. For p=1, EDG will require only 21 blocks, meaning that the p=3 Jacobian matrix will have 50 times more non-zeros as the p=1 case.


The advantage of using a time-implicit method is that a much larger time step can be selected compared to an explicit method. This is particularly true for high order methods, where the time step restrictions are more stringent than that of their low order counterparts.

In the current implementation, the CPU time required for each time step stage is usually only 4 or so times greater than that of computing the residual. However, the solver can generally use a time step 100 or more times larger than explicit DG methods, giving an increase in performance of more than an order of magnitude.


More information on how the EDG and HDG methods scale can be found in the second reference on the website.

[arjun]

Thank you for explanation.
Very interesting work.

[fivos]

Really very impressive, well done..

Does this work with arbitrary EOS (Peng Robinson, custom User defined e.g. table), or only for ideal gas?

Also are you planning to release source code?

Thanks

[mavguy]

Hi fivos,

Unfortunately, the only EOS that is currently supported is ideal gas. If there is enough interest we could look into adding other ones. What application are you thinking about?

I do not currently plan on distributing the source.

[fivos]

Hi Mavguy (John),

Thanks for responding.. My question was of more general aspect.. since you managed to build such a powerful solver with high order capabilities, it is a pity not to implement additional equations of state (EOS), for e.g. high speed external aerodynamics, re-entry vehicles, combustion/deflagration/detonation (though these will need chemistry also) bubble dynamics, or even cavitation (on which I am working), all of which may need something better than the standard ideal gas EOS.

I understand that going to more complicated EOS will make things much more complicated regarding the thermodynamics, but it might be worth the effort.. Out of curiosity, you solve for the conservative variable set [ρ, ρu, .., E] or for the pressure, velocities, temperature? I would expect the former for compressible applications and density waves as those you show (didn't have the time to look your references, sorry..)..

Regarding not releasing the source code, I understand that, but maybe having the software open will allow more contributions (and more citations..). Anyway its your code you choose

Thanks again.

[mavguy]

Thanks for the interest, fivos.

It sure would be nice to have all of those capabilities, but right now it's baby steps. Just trying to make high order methods competitive with their low order counterparts is quite a challenge.

As far as supersonic and hypersonic flow is concerned: it can be done, but the code does not handle shocks very well yet. An artificial viscosity model will be added in the future to help with this.

And yes, the numerical scheme is conservative.

[Martin Hegedus]

Quick bullet points:

1) Looks cool and I'm interested in trying it out and comparing it to Aero Troll. http://www.hegedusaero.com/software.html

2) IMO, a turbulence model is very important. Otherwise everything of normal Re will be unsteady regardless of how streamlined the shape is.

3) Going open source is probably of no benefit. Even though Aero Troll is of use to people, basically no one has donated any money to it. It's become a labor of love.

Good Luck!

[zhuhui]

Hi,
Your solver looks pretty cool!
I've been working on a high-order solver as well, and I have some questions:
1. What kind of shock capturing technique do you use?
2. What kind of preconditioner do you use for GMRES?
3. Is your solver able to simulate turbulent flow?
I'm looking forward to your reply! Thanks!

[mavguy]

Hi zhuhui,

To answer your questions:

1. I don't currently use any shock capturing techniques. I just cross my fingers and hope that the physical viscosity is enough to dissipate the shock. However, implementing shock capturing via artificial viscosity is on the books for the near future.

2. I use block ILU(0) as a preconditioner.

3. Currently, I do not have a turbulence model implemented. However, I do plan to implement RANS in the near future. In it's current state, the solver can only solve implicit LES turbulent flows.

What type of high-order solver are you developing?

[zhuhui]

FR/CPR method.