No worries. I had making my Wetropolis mesh on my agenda first so I could wait. But have not found time yet. Obviously then I would need the gmsh option in flood drake but when I have the mesh for Wetropolis made then I will tell you. Thanks. ________________________________ From: firedrake-bounces@imperial.ac.uk <firedrake-bounces@imperial.ac.uk> on behalf of Gregory, Alastair C A <a.gregory14@imperial.ac.uk> Sent: Wednesday, August 10, 2016 4:43 PM To: firedrake Subject: Re: [firedrake] flood drake query Hi Onno, When the checks for this pull request have passed (very soon), I will merge. However there are some still some bugs (highlighted in the flooding example you queried about) so I advise you to wait another day before pulling master until I have pushed some changes that sort these out. This fix will come alongside adaptive time-stepping which I have done today. Apologies for the delay. Many Thanks, Ali Alastair Gregory ------------------------------------------------------------------- Research Assistant (Maths Foresees Grant) Imperial College London Office 759 Huxley Building, South Kensington (Tel: 07794 243913) | (Email: a.gregory14@imperial.ac.uk) ------------------------------------------------------------------------------------ ________________________________ From: firedrake-bounces@imperial.ac.uk <firedrake-bounces@imperial.ac.uk> on behalf of Onno Bokhove <O.Bokhove@leeds.ac.uk> Sent: 09 August 2016 14:32:05 To: firedrake Subject: Re: [firedrake] flood drake query Waiting for the merge! ________________________________ From: firedrake-bounces@imperial.ac.uk <firedrake-bounces@imperial.ac.uk> on behalf of Gregory, Alastair C A <a.gregory14@imperial.ac.uk> Sent: Tuesday, August 9, 2016 1:31 PM To: firedrake Subject: Re: [firedrake] flood drake query Hi Onno, "- has there been an update with a gmsh example in which solid walls and inflow/outflow/specified flow conditions have been imposed at the boundaries" There has not as of yet. The current set-up conditions are only for firedrake Mesh's and for reflective boundary conditions off of solid walls. "has the time step been made adaptable based on flood/signal speeds" Again not as yet, this will definitely be done though. At the moment, we specify a value of dt/dx and this dictates the timestep. This is an argument labelled as Courant in Timestepper class. See help(Timestepper). "I tried daybreak over uniform beach and lowered the time step (adaptable one preferred) but am not sure whether the slope limiter causes some spurious oscillations. Does the Ern slope limiter approach add an extra time step restriction above and beyond the normal CFL* min_dx/|lambda| with CFL<1 and lambda = |u|+ sort (g h)?" So this was a bug that came about from not slope limiting the momentum as well as the depth. This is in the latest pull request of the package but hasn't yet been accepted to merge. If you want to try this out, you may just copy straight off of the branch in which this update is on. There isn't an extra condition as I know of. "Also the speed seems a bit low although I aim to run it against a 2D c-code I once made." The speed is slow for 2D but this is as fast as I can get it for the time being. I will continue to look further into why this could be. Hope this helps and gives you an update. Many Thanks, Ali Alastair Gregory ------------------------------------------------------------------- Research Assistant (Maths Foresees Grant) Imperial College London Office 759 Huxley Building, South Kensington (Tel: 07794 243913) | (Email: a.gregory14@imperial.ac.uk) ------------------------------------------------------------------------------------ ________________________________ From: firedrake-bounces@imperial.ac.uk <firedrake-bounces@imperial.ac.uk> on behalf of Onno Bokhove <O.Bokhove@leeds.ac.uk> Sent: 09 August 2016 12:56:03 To: firedrake Subject: [firedrake] flood drake query Hi, Using/adapting flood drake: - has there been an update with a gmsh example in which solid walls and inflow/outflow/specified flow conditions have been imposed at the boundaries - has the time step been made adaptable based on flood/signal speeds. - I tried daybreak over uniform beach and lowered the time step (adaptable one preferred) but am not sure whether the slope limiter causes some spurious oscillations. Does the Ern slope limiter approach add an extra time step restriction above and beyond the normal CFL* min_dx/|lambda| with CFL<1 and lambda = |u|+ sort (g h)? - Also the speed seems a bit low although I aim to run it against a 2D c-code I once made. Thank you, Onno See code snippet below. """ demo file for simple 2d shallow water equations flooding on a slope """ from __future__ import division from firedrake import * from flooddrake import * # Meshsize n = 5 mesh = UnitSquareMesh(10*n, n) # mixed function space v_h = FunctionSpace(mesh, "DG", 1) v_mu = FunctionSpace(mesh, "DG", 1) v_mv = FunctionSpace(mesh, "DG", 1) V = v_h*v_mu*v_mv # for slope limiter v_hcg = FunctionSpace(mesh, "CG", 1) v_mucg = FunctionSpace(mesh, "CG", 1) v_mvcg = FunctionSpace(mesh, "CG", 1) VCG = v_hcg*v_mucg*v_mvcg # setup free surface depth g = Function(V) x = SpatialCoordinate(V.mesh()) g.sub(0).interpolate(conditional(x[0] < 0.2, 3.0/9.8, 0.0)) # setup bed bed = Function(V) # setup actual depth w = g.assign(g - bed) x = SpatialCoordinate(V.mesh()) bed.sub(0).interpolate(0.25*x[0]) # setup source (is only a depth function) source = Function(v_h) # timestep solution = Timestepper(V, VCG, bed, source, 0.0065) solution.stepper(0, 2, w, 0.025)