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)
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)
Thank you Ali. Great work. I am aiming to set up your code for the river etc in Wetropolis, hence my queries: https://www.facebook.com/resurging.flows Onno ________________________________ 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:37 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)
On 9 Aug 2016, at 13:31, Gregory, Alastair C A <a.gregory14@imperial.ac.uk> wrote:
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.
I suspect that one thing that may be going on is that most of your integrands are non-polynomial. UFL attempts to integrate your forms exactly using numerical quadrature. Since the basis is polynomial this is not possible for your integrands. In this case, UFL resorts to heuristics to come up with a quadrature rule that is "exact enough". These heuristics are rather conservative, and can therefore result in excessively high degree quadrature rules. Probably for convergence you only care about integrating the mass matrix exactly. As such, you should probably specify your quadrature degree "by hand". You do this by __call__ing the measure objects passing in the keyword argument degree. For example: Rather than writing: dot(v, boundary_flux)*ds you write: dot(v, boundary_flux)*ds(degree=4) # Integrate degree 4 polynomials exactly The advice I gave to Justin earlier today about profiling using PETSc tools applies here too. Cheers, Lawrence
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)
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)
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)
Hi flooddrakers, (i) Has flood drake been updated yet wrt the error in the slope limiter? The github link is still old it seems? (ii) Also would it be possible to update the boundaries (numbered I guess) with an outside (left flux) which is a function of (a) specified functions and (b) the inside (right) values of the variables (h, mu and mv) such that the user can specify complicated bc's, including a solid wall, influx/outflux determined by the numerical flux, etc.? Per our discussion yesterday in Edinburgh? That would be awesome. Best, Onno ________________________________ From: firedrake-bounces@imperial.ac.uk <firedrake-bounces@imperial.ac.uk> on behalf of Onno Bokhove <O.Bokhove@leeds.ac.uk> Sent: Wednesday, August 10, 2016 4:51 PM To: firedrake Subject: Re: [firedrake] flood drake query 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)
Hi Onno, I'll start with (ii): Yes this will be done in time - unfortunately it won't be until next week until I've had a chance to chat with Colin about the best way of doing this. It will have an option though hopefully that will allow you to pick (a) or (b) here depending on your choice of boundaries. On to (i): Nope, this got merged 23 days ago it says on Github - make sure you're looking at master. I'm about to push through a new branch that gives you a bit more control over some parameters you can choose for each demo (like epsilon, the negligible water depth). This should be done tomorrow. Many Thanks, 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: 08 September 2016 16:26:42 To: firedrake Subject: Re: [firedrake] flood drake query Hi flooddrakers, (i) Has flood drake been updated yet wrt the error in the slope limiter? The github link is still old it seems? (ii) Also would it be possible to update the boundaries (numbered I guess) with an outside (left flux) which is a function of (a) specified functions and (b) the inside (right) values of the variables (h, mu and mv) such that the user can specify complicated bc's, including a solid wall, influx/outflux determined by the numerical flux, etc.? Per our discussion yesterday in Edinburgh? That would be awesome. Best, Onno ________________________________ From: firedrake-bounces@imperial.ac.uk <firedrake-bounces@imperial.ac.uk> on behalf of Onno Bokhove <O.Bokhove@leeds.ac.uk> Sent: Wednesday, August 10, 2016 4:51 PM To: firedrake Subject: Re: [firedrake] flood drake query 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)
participants (3)
-
Gregory, Alastair C A
-
Lawrence Mitchell
-
Onno Bokhove