September 2016 - firedrake

Re: [firedrake] flood drake query
by Colin Cotter 08 Sep '16

08 Sep '16

Hi Onno, Regarding (ii), please can you add this as an issue on Github. all the best --cjc On 8 September 2016 at 16:26, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > 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(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of Onno Bokhove <O.Bokhove(a)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(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of Gregory, Alastair C A <a.gregory14(a)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(a)imperial.ac.uk > <a.gregory14(a)imperial.ac.uk>)* > ------------------------------------------------------------ > ------------------------ > ------------------------------ > *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of Onno Bokhove <O.Bokhove(a)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(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of Gregory, Alastair C A <a.gregory14(a)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(a)imperial.ac.uk > <a.gregory14(a)imperial.ac.uk>)* > ------------------------------------------------------------ > ------------------------ > ------------------------------ > *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of Onno Bokhove <O.Bokhove(a)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) > > -- http://www.imperial.ac.uk/people/colin.cotter www.cambridge.org/9781107663916

1 0

Re: [firedrake] Mixed system DirichletBC - mismatching function spaces
by Colin Cotter 07 Sep '16

07 Sep '16

Yes, I would always try weak BCs first. On 6 September 2016 at 17:37, Ham, David A <david.ham(a)imperial.ac.uk> wrote: > At a random guess, I think it might work to apply that BC weakly (ie > (u1-u2)*dx). However one would need to see the code. > > On Tue, 6 Sep 2016 at 17:31, Mitchell, Lawrence < > lawrence.mitchell(a)imperial.ac.uk> wrote: > >> Dear Anna, >> >> On 06/09/16 17:19, Anna Kalogirou wrote: >> > Dear all, >> > >> > I have the following sample code which gives a ValueError: Mismatching >> > function spaces. >> > >> > ## >> > >> > V = FunctionSpace(mesh, "CG", 1) >> > W = V*V >> > >> > w = Function(W) >> > v1, v2 = TestFunctions(W) >> > u1, u2 = split(w) >> > >> > F1 = F(u1, u2) # function of u1 and u2 >> > >> > F2 = F(u2) # function of u2 only >> > >> > bc = DirichletBC(W.sub(1), u1, 'top’) # BC for F2 >> > >> > u_problem = NonlinearVariationalProblem(F1 + F2, w, bcs=[bc]) >> > >> > ## >> > >> > Note that the second equation depends on u1 through the DirichletBC >> > only. Is the error generated due to the fact that u1 comes from >> > W.sub(0) and it is given as a BC on W.sub(0)? >> >> There are two problems here. >> >> 1. u1 is indexed with component 0, but you're trying to apply it to >> component 1 (which is why you get the proximate error). >> >> 2. This is the bigger problem. >> >> The way you've formulated the problem, even if you removed the error >> from (1), which would be possible I think, doesn't do what you think >> it does. We don't support problems where the solution is coupled to >> itself through the boundary condition. So what would happen is you >> would end up minimising the residual for F2 subject to the value of u1 >> on the boundary, *when you started the solve* (i.e. whatever initial >> guess you had for u1). >> >> I think it might be possible to vary how firedrake works to do what >> you want, but one would have to work out what's going on on paper >> first. http://firedrakeproject.org/boundary_conditions.html describes >> the maths (and the implementation strategy) for applying boundary >> conditions. Can you see how to modify it so that it still works if >> the boundary condition value depends on the state variable? >> >> Lawrence >> >> -- http://www.imperial.ac.uk/people/colin.cotter www.cambridge.org/9781107663916

1 0

Re: [firedrake] Mixed system DirichletBC - mismatching function spaces
by David Ham 06 Sep '16

06 Sep '16

At a random guess, I think it might work to apply that BC weakly (ie (u1-u2)*dx). However one would need to see the code. On Tue, 6 Sep 2016 at 17:31, Mitchell, Lawrence < lawrence.mitchell(a)imperial.ac.uk> wrote: > Dear Anna, > > On 06/09/16 17:19, Anna Kalogirou wrote: > > Dear all, > > > > I have the following sample code which gives a ValueError: Mismatching > > function spaces. > > > > ## > > > > V = FunctionSpace(mesh, "CG", 1) > > W = V*V > > > > w = Function(W) > > v1, v2 = TestFunctions(W) > > u1, u2 = split(w) > > > > F1 = F(u1, u2) # function of u1 and u2 > > > > F2 = F(u2) # function of u2 only > > > > bc = DirichletBC(W.sub(1), u1, 'top’) # BC for F2 > > > > u_problem = NonlinearVariationalProblem(F1 + F2, w, bcs=[bc]) > > > > ## > > > > Note that the second equation depends on u1 through the DirichletBC > > only. Is the error generated due to the fact that u1 comes from > > W.sub(0) and it is given as a BC on W.sub(0)? > > There are two problems here. > > 1. u1 is indexed with component 0, but you're trying to apply it to > component 1 (which is why you get the proximate error). > > 2. This is the bigger problem. > > The way you've formulated the problem, even if you removed the error > from (1), which would be possible I think, doesn't do what you think > it does. We don't support problems where the solution is coupled to > itself through the boundary condition. So what would happen is you > would end up minimising the residual for F2 subject to the value of u1 > on the boundary, *when you started the solve* (i.e. whatever initial > guess you had for u1). > > I think it might be possible to vary how firedrake works to do what > you want, but one would have to work out what's going on on paper > first. http://firedrakeproject.org/boundary_conditions.html describes > the maths (and the implementation strategy) for applying boundary > conditions. Can you see how to modify it so that it still works if > the boundary condition value depends on the state variable? > > Lawrence > >

1 0

Mixed system DirichletBC - mismatching function spaces
by Anna Kalogirou 06 Sep '16

06 Sep '16

Dear all, I have the following sample code which gives a ValueError: Mismatching function spaces. ## V = FunctionSpace(mesh, "CG", 1) W = V*V w = Function(W) v1, v2 = TestFunctions(W) u1, u2 = split(w) F1 = F(u1, u2) # function of u1 and u2 F2 = F(u2) # function of u2 only bc = DirichletBC(W.sub(1), u1, 'top’) # BC for F2 u_problem = NonlinearVariationalProblem(F1 + F2, w, bcs=[bc]) ## Note that the second equation depends on u1 through the DirichletBC only. Is the error generated due to the fact that u1 comes from W.sub(0) and it is given as a BC on W.sub(0)? Best, Anna.

2 1