Hi Julian, thanks a lot for your reply, I will have a look at this. We'd need a compressible solver which can also deal with high Reynolds numbers. Are you using Chorin's projection method for the pressure update? Eike On Thu, 2017-07-06 at 14:02 +0200, Julian Andrej wrote:
We have an experimental implementation of the time dependent, fully implicit incompressible NS equation in this repository https://github.com/JuLuSi/incflow
It is stabilized using the Galerkin Least Squares method. If this would work for you as a basis i can guide you through the implementation, although its not very complex but has a few implementation details that took me some time to understand. Obviously there is no AMR support.
On Thu, Jul 6, 2017 at 12:56 PM, Lawrence Mitchell <lawrence.mitchell@imperial.ac.uk> wrote:
Hi Eike, Andrew,
On 5 Jul 2017, at 18:15, Eike Mueller <E.Mueller@bath.ac.uk> wrote:
Dear Firedrakers,
has anyone ever used Firedrake to solve the (fully compressible) Navier-Stokes equations in engineering applications? I’m talking to a colleague here in Bath who would like to model the flow of air around an aircraft wing, and am trying to find out how best to approach this. The flow is turbulent in some regions, but smooth in others. Not exactly sure which equations and turbulence model would be appropriate, but I suspect it will require (adaptive) refinement in parts of the domain where the turbulent eddies are shedded.
So we have some (very preliminary) support for mesh adaptivity. But it doesn't work in parallel yet.
So you want to do time-dependent NS? What kind of target Reynolds numbers? Are you anticipating explicit or implicit schemes? If implicit, note that none of the classic block preconditioners are Re-independent (so high reynolds number is a problem).
I don't know of anyone who has done high Re time-dependent flow in Firedrake (that's not to say that no-one has).
Also, the domain to be modeled would contain a hole (which is taken up by the wing) and we’d likely use an unstructured mesh. The wing is allowed to transform. For this a continuum mechanics code implemented in DUNE is used, so we would need to feed this the boundary conditions from Firedrake. As a result of the DUNE calculation, the Firedrake mesh would change from one timestep to the next.
Geometrically (i.e. you deform), or topologically (i.e. you remesh)? If you're remeshing, how would you like to transfer fields? We can only do consistent interpolation right now.
It might be possible to re-write the DUNE code in Firedrake, but it contains a very specific multigrid-preconditioner developed by Rob’s group and implemented by Linus Seelinger, which uses global eigenfunctions in the coarse space - so can’t just throw AMG at it.
This kind of coupling is going to be quite fiddly (especially if you want to run in parallel [almost certain for 3D]), but could be done.
Lawrence _______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake