June 2016 - firedrake - imperial.ac.uk

Re: [firedrake] upwind example remark; extension to CN in time
by Andrew McRae 27 Jun '16

27 Jun '16

(For simplicity, I'll assume an explicit timestepping method) You have a field from your previous timestep; let's call this U_ You represent your boundary data using some other field; let's call this U0. (Note: Firedrake can't yet represent fields that "only exist on the boundary", so U0 will just be a normal global function, but we will only make use of its boundary values, so it can be nonsense or zero in the interior) On the LHS of your equation, you just have a mass matrix (assume you are solving for the new field U, or for the increment dU, it doesn't matter) On the RHS, you have some cell integral after integrating by parts, some integral over interior facets that uses U_('+'), U_('-'), n('+') and n('-')***, and some integral over exterior facets that uses U_, U0, and n. If your interior facet flux integral was dot(jump(phi), un('+')*U('+') - un( '-')*U('-'))*dS (where un is u.n if this is positive, else 0; u is the velocity field), your exterior facet flux integral could be dot(phi, un*U_ + (dot(u, n) - un)*U0)*ds [Gevaar: may contain sign errors] ***: Usually n('-') is -n('+'), but since we separate the mesh geometry from the mesh topology, this doesn't have to be true <http://www.firedrakeproject.org/extruded-meshes.html#hedgehog-extrusion>. On 27 June 2016 at 11:40, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > So how would you implement a standard numerical flux at the > > boundary that uses a mix of information from the outside and given > > -which I would call "+", as well as the interior or "-" information? > > In other words it needs a U+ and a U-? > > > Using the standard and same numerical flux used everywhere else > > in the interior (i.e. needing a U+ and U- as input as well) except that > one piece of information is supplied? Basically a ghost value? Is > that not allowed? > > > > ------------------------------ > *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of Andrew McRae <A.T.T.McRae(a)bath.ac.uk> > *Sent:* Monday, June 27, 2016 11:33 AM > > *To:* firedrake(a)imperial.ac.uk > *Subject:* Re: [firedrake] upwind example remark; extension to CN in time > > Again, we do not use + and - on exterior facets. > > On 27 June 2016 at 11:29, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > >> Ah, that is: in our usual set-up at any face there is an orientation >> chosen with one of the normals being called outside. >> >> That is arbitrary but once fixed it is known. >> >> In the interior that does not matter but at real boundaries >> >> the convention is always that the normal assigned is the >> >> normal pointing outside the domain. >> >> That is why at real boundaries one knows which sign convention >> >> concerns outside information. >> >> Otherwise how do you know whether to assign an outside the >> >> domain value to + or -? You would not know. >> >> >> In my convention with - inside, the + side is then the given >> >> information from the outside. >> >> >> ------------------------------ >> *From:* firedrake-bounces(a)imperial.ac.uk < >> firedrake-bounces(a)imperial.ac.uk> on behalf of Colin Cotter < >> colin.cotter(a)imperial.ac.uk> >> *Sent:* Monday, June 27, 2016 7:41 AM >> *To:* firedrake >> *Subject:* Re: [firedrake] upwind example remark; extension to CN in time >> >> Hi Onno, >> But + and - are not on the inside or outside, they are just two >> arbitrary sides. >> >> I'll look into why the code is crashing today hopefully, I have a phone >> conference about admissions until 4pm. >> >> all the best >> >> --cjc >> >> On 27 June 2016 at 04:34, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >> >>> Hi Colin, >>> >>> >>> I know that of course as that is how I loop in my own c or matlab >>> >>> programs! One loop over elements and one loop over the faces. >>> >>> >>> I am just saying state in the documentation example >>> >>> that plus is on the inside when the normal is pointing outward, >>> >>> and minus on the outside. Just add one sentence. >>> >>> I usually tend to do that the other way around as >>> >>> it is the limit with -epsilon and epsilon positive that is on the inside >>> (so minus not plus is my usual convention; it does not matter but define it >>> also >>> >>> in the documentation example for clarity). >>> >>> >>> * The one remaining issue in my code seems that FD does not like me to >>> use D_(+) or D_(-) while D(+) and D(-) are allowed, with the one >>> >>> difference being that D is a TrailFunction >>> >>> and D_ (previous time step) a Function. >>> >>> I guess I don't understand that difference yet. >>> >>> >>> Thanks for the UFL link. That will help. >>> >>> >>> Best wishes, >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> *From:* firedrake-bounces(a)imperial.ac.uk < >>> firedrake-bounces(a)imperial.ac.uk> on behalf of Colin Cotter < >>> colin.cotter(a)imperial.ac.uk> >>> *Sent:* Sunday, June 26, 2016 3:11 PM >>> >>> *To:* firedrake >>> *Subject:* Re: [firedrake] upwind example remark; extension to CN in >>> time >>> >>> Hi Onno, >>> This is documented in the UFL manual (the plusses, minusses etc.). >>> >>> fenicsproject.org/pub/documents/*ufl*/*ufl*-user-*manual*/*ufl*-user- >>> *manual*.pdf >>> >>> The reason for this notation is that UFL is written for a global domain, >>> in particular for facets it is the union of all interior facets, and when >>> surface integrals are done, the facets are visited one by one instead of >>> the cells. This means that there needs to be an (arbitrary) labelling of + >>> and - sides of each facet. The notation was originally invented to write >>> down global inner products to analyse DG methods for elliptic problems, >>> where it is completely standard. This notation was set out in >>> Arnold, Douglas N., et al. "Unified analysis of discontinuous Galerkin >>> methods for elliptic problems." *SIAM journal on numerical analysis* 39.5 >>> (2002): 1749-1779. >>> >>> all the best >>> --cjc >>> >>> On 26 June 2016 at 14:08, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >>> >>>> Sure I knew that. D+ is on the inside of a cell with n pointing outward >>>> >>>> unless I am blinded by being on the other side of the world. >>>> >>>> Bit unusual convention in the DG world. Usually minus is on the inside. >>>> >>>> But could it as such be defined in the write-up/documentation please? >>>> >>>> In any DG article the convention whatever it is gets defined. >>>> >>>> >>>> ------------------------------ >>>> *From:* firedrake-bounces(a)imperial.ac.uk < >>>> firedrake-bounces(a)imperial.ac.uk> on behalf of Andrew McRae < >>>> A.T.T.McRae(a)bath.ac.uk> >>>> *Sent:* Sunday, June 26, 2016 12:40 PM >>>> *To:* firedrake(a)imperial.ac.uk >>>> >>>> *Subject:* Re: [firedrake] upwind example remark; extension to CN in >>>> time >>>> >>>> D+ and D- refer to the values either side of an interior facet between >>>> two cells. >>>> >>>> On the boundary (exterior facets), there is no such ambiguity, so just >>>> D is used. >>>> >>>> In the steady-state example on the website, this D enters the >>>> left-hand-side integral over the outflow part of the boundary, while the >>>> prescribed function D0 is used in the integral over the inflow part. >>>> >>>> "In general", you can write a term that contains both D and D0 and >>>> 'picks the right one' depending on the sign of u.n (this is how the >>>> interior facet integral works). Note that n always points *outwards* on >>>> the exterior boundary facets. >>>> >>>> On 26 June 2016 at 12:24, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >>>> >>>>> The issue is that D_('+') (or D_('-')) is not defined but I don't >>>>> understand why not, or how to fix it? >>>>> >>>>> >>>>> ------------------------------ >>>>> *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:* Sunday, June 26, 2016 12:21 PM >>>>> >>>>> *To:* firedrake >>>>> *Subject:* Re: [firedrake] upwind example remark; extension to CN in >>>>> time >>>>> >>>>> >>>>> Yes that was my point indeed. >>>>> >>>>> To build any more advanced code upon this one, one >>>>> >>>>> would need to use an alternate approach entirely >>>>> >>>>> through the flux. >>>>> >>>>> That is why it may be useful to extend the >>>>> >>>>> example with two alternatives: the simple one shown >>>>> >>>>> and one flux-based only. >>>>> >>>>> >>>>> By the way, in the attached I have L2=0 and thet=0; >>>>> >>>>> if I uncomment the actual L2 there is a complaint, >>>>> >>>>> even though they=0. >>>>> >>>>> Obviously I need this term for the general theta-scheme, >>>>> >>>>> including thet=0.5 (Crank-Nicolson). >>>>> >>>>> I am doing the above simple extensions to get used to FD! >>>>> Small steps ... >>>>> >>>>> The example is ties such that value 1 advects into through the >>>>> entire domain in the time set. >>>>> ------------------------------ >>>>> *From:* firedrake-bounces(a)imperial.ac.uk < >>>>> firedrake-bounces(a)imperial.ac.uk> on behalf of Colin Cotter < >>>>> colin.cotter(a)imperial.ac.uk> >>>>> *Sent:* Sunday, June 26, 2016 11:26 AM >>>>> *To:* firedrake >>>>> *Subject:* Re: [firedrake] upwind example remark; extension to CN in >>>>> time >>>>> >>>>> Hi Onno, >>>>> In answer to your first question. Things are simplified in the >>>>> advection demo because we know which edges are upwind, which are downwind, >>>>> and which have no flow through them. If you wanted to generalise this, then >>>>> we would need a surface integral over the entire external boundary with a >>>>> switch that either gave the internal value of the tracer or the inflow >>>>> boundary condition, depending on the direction of u.n, just like we did for >>>>> the interior facets. >>>>> Instead, in this example, on the outflow boundary we just write an >>>>> integral involving the interior value, and on the inflow boundary we write >>>>> an integral setting the inflow values. >>>>> >>>>> all the best >>>>> -cjc >>>>> >>>>> On 25 June 2016 at 16:05, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >>>>> >>>>>> Hi FDs, >>>>>> >>>>>> >>>>>> (i) The upwind example is odd in that the real boundaries are treated >>>>>> >>>>>> in a special way rather than setting the outside value in >>>>>> >>>>>> the same numerical flux as anywhere else; >>>>>> >>>>>> my question is how this can be fixed? >>>>>> >>>>>> So no special terms at the in- and outflow, just specify >>>>>> >>>>>> the outside velocity used. This is imo the proper DG way not was is >>>>>> done >>>>>> >>>>>> now. >>>>>> >>>>>> >>>>>> (ii) Attached my attempt to do a time dependent advection >>>>>> >>>>>> with Crank Nicolson, which works but does not yet >>>>>> >>>>>> give the right answer, in part due to (i). >>>>>> >>>>>> >>>>>> [I don't understand why I have to make >>>>>> >>>>>> my theta variable that a constant but other wise it did not work.] >>>>>> >>>>>> Any suggestions, corrections, also on other silly things done by me? >>>>>> >>>>>> Next step is to extend to system with 3 equations; >>>>>> hence the few extra but unused variables. >>>>>> >>>>>> Thanks, from midnight Seoul in old style Korean guesthouse. >>>>>> >>>>>> Onno >>>>>> ------------------------------ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> http://www.imperial.ac.uk/people/colin.cotter >>>>> >>>>> www.cambridge.org/9781107663916 >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> http://www.imperial.ac.uk/people/colin.cotter >>> >>> www.cambridge.org/9781107663916 >>> >>> >>> >> >> >> -- >> http://www.imperial.ac.uk/people/colin.cotter >> >> www.cambridge.org/9781107663916 >> >> >> >

1 0

Re: [firedrake] upwind example remark; extension to CN in time
by David Ham 27 Jun '16

27 Jun '16

On an exterior facet, FacetNormal points out of the domain. This is sufficient. For example, suppose I have a velocity field u, then: u_out = 0.5* (dot(u, n) + abs(dot(u, n))) is equal to the outward flux when the velocity goes out of the domain, and 0 when the velocity is coming in. This is sufficient to select between the field value inside the domain, and a prescribed boundary value. More complex flux decisions can be created in a similar manner. Regards, David On Mon, 27 Jun 2016 at 11:43 Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > So how would you implement a standard numerical flux at the > > boundary that uses a mix of information from the outside and given > > -which I would call "+", as well as the interior or "-" information? > > In other words it needs a U+ and a U-? > > > Using the standard and same numerical flux used everywhere else > > in the interior (i.e. needing a U+ and U- as input as well) except that > one piece of information is supplied? Basically a ghost value? Is > that not allowed? > > > > ------------------------------ > *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of Andrew McRae <A.T.T.McRae(a)bath.ac.uk> > *Sent:* Monday, June 27, 2016 11:33 AM > > *To:* firedrake(a)imperial.ac.uk > *Subject:* Re: [firedrake] upwind example remark; extension to CN in time > Again, we do not use + and - on exterior facets. > > On 27 June 2016 at 11:29, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > >> Ah, that is: in our usual set-up at any face there is an orientation >> chosen with one of the normals being called outside. >> >> That is arbitrary but once fixed it is known. >> >> In the interior that does not matter but at real boundaries >> >> the convention is always that the normal assigned is the >> >> normal pointing outside the domain. >> >> That is why at real boundaries one knows which sign convention >> >> concerns outside information. >> >> Otherwise how do you know whether to assign an outside the >> >> domain value to + or -? You would not know. >> >> >> In my convention with - inside, the + side is then the given >> >> information from the outside. >> >> >> ------------------------------ >> *From:* firedrake-bounces(a)imperial.ac.uk < >> firedrake-bounces(a)imperial.ac.uk> on behalf of Colin Cotter < >> colin.cotter(a)imperial.ac.uk> >> *Sent:* Monday, June 27, 2016 7:41 AM >> *To:* firedrake >> *Subject:* Re: [firedrake] upwind example remark; extension to CN in time >> >> Hi Onno, >> But + and - are not on the inside or outside, they are just two >> arbitrary sides. >> >> I'll look into why the code is crashing today hopefully, I have a phone >> conference about admissions until 4pm. >> >> all the best >> >> --cjc >> >> On 27 June 2016 at 04:34, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >> >>> Hi Colin, >>> >>> >>> I know that of course as that is how I loop in my own c or matlab >>> >>> programs! One loop over elements and one loop over the faces. >>> >>> >>> I am just saying state in the documentation example >>> >>> that plus is on the inside when the normal is pointing outward, >>> >>> and minus on the outside. Just add one sentence. >>> >>> I usually tend to do that the other way around as >>> >>> it is the limit with -epsilon and epsilon positive that is on the inside >>> (so minus not plus is my usual convention; it does not matter but define it >>> also >>> >>> in the documentation example for clarity). >>> >>> >>> * The one remaining issue in my code seems that FD does not like me to >>> use D_(+) or D_(-) while D(+) and D(-) are allowed, with the one >>> >>> difference being that D is a TrailFunction >>> >>> and D_ (previous time step) a Function. >>> >>> I guess I don't understand that difference yet. >>> >>> >>> Thanks for the UFL link. That will help. >>> >>> >>> Best wishes, >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> *From:* firedrake-bounces(a)imperial.ac.uk < >>> firedrake-bounces(a)imperial.ac.uk> on behalf of Colin Cotter < >>> colin.cotter(a)imperial.ac.uk> >>> *Sent:* Sunday, June 26, 2016 3:11 PM >>> >>> *To:* firedrake >>> *Subject:* Re: [firedrake] upwind example remark; extension to CN in >>> time >>> >>> Hi Onno, >>> This is documented in the UFL manual (the plusses, minusses etc.). >>> >>> fenicsproject.org/pub/documents/*ufl*/*ufl*-user-*manual*/*ufl*-user- >>> *manual*.pdf >>> >>> The reason for this notation is that UFL is written for a global domain, >>> in particular for facets it is the union of all interior facets, and when >>> surface integrals are done, the facets are visited one by one instead of >>> the cells. This means that there needs to be an (arbitrary) labelling of + >>> and - sides of each facet. The notation was originally invented to write >>> down global inner products to analyse DG methods for elliptic problems, >>> where it is completely standard. This notation was set out in >>> Arnold, Douglas N., et al. "Unified analysis of discontinuous Galerkin >>> methods for elliptic problems." *SIAM journal on numerical analysis* 39.5 >>> (2002): 1749-1779. >>> >>> all the best >>> --cjc >>> >>> On 26 June 2016 at 14:08, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >>> >>>> Sure I knew that. D+ is on the inside of a cell with n pointing outward >>>> >>>> unless I am blinded by being on the other side of the world. >>>> >>>> Bit unusual convention in the DG world. Usually minus is on the inside. >>>> >>>> But could it as such be defined in the write-up/documentation please? >>>> >>>> In any DG article the convention whatever it is gets defined. >>>> >>>> >>>> ------------------------------ >>>> *From:* firedrake-bounces(a)imperial.ac.uk < >>>> firedrake-bounces(a)imperial.ac.uk> on behalf of Andrew McRae < >>>> A.T.T.McRae(a)bath.ac.uk> >>>> *Sent:* Sunday, June 26, 2016 12:40 PM >>>> *To:* firedrake(a)imperial.ac.uk >>>> >>>> *Subject:* Re: [firedrake] upwind example remark; extension to CN in >>>> time >>>> >>>> D+ and D- refer to the values either side of an interior facet between >>>> two cells. >>>> >>>> On the boundary (exterior facets), there is no such ambiguity, so just >>>> D is used. >>>> >>>> In the steady-state example on the website, this D enters the >>>> left-hand-side integral over the outflow part of the boundary, while the >>>> prescribed function D0 is used in the integral over the inflow part. >>>> >>>> "In general", you can write a term that contains both D and D0 and >>>> 'picks the right one' depending on the sign of u.n (this is how the >>>> interior facet integral works). Note that n always points *outwards* on >>>> the exterior boundary facets. >>>> >>>> On 26 June 2016 at 12:24, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >>>> >>>>> The issue is that D_('+') (or D_('-')) is not defined but I don't >>>>> understand why not, or how to fix it? >>>>> >>>>> >>>>> ------------------------------ >>>>> *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:* Sunday, June 26, 2016 12:21 PM >>>>> >>>>> *To:* firedrake >>>>> *Subject:* Re: [firedrake] upwind example remark; extension to CN in >>>>> time >>>>> >>>>> >>>>> Yes that was my point indeed. >>>>> >>>>> To build any more advanced code upon this one, one >>>>> >>>>> would need to use an alternate approach entirely >>>>> >>>>> through the flux. >>>>> >>>>> That is why it may be useful to extend the >>>>> >>>>> example with two alternatives: the simple one shown >>>>> >>>>> and one flux-based only. >>>>> >>>>> >>>>> By the way, in the attached I have L2=0 and thet=0; >>>>> >>>>> if I uncomment the actual L2 there is a complaint, >>>>> >>>>> even though they=0. >>>>> >>>>> Obviously I need this term for the general theta-scheme, >>>>> >>>>> including thet=0.5 (Crank-Nicolson). >>>>> >>>>> I am doing the above simple extensions to get used to FD! >>>>> Small steps ... >>>>> >>>>> The example is ties such that value 1 advects into through the >>>>> entire domain in the time set. >>>>> ------------------------------ >>>>> *From:* firedrake-bounces(a)imperial.ac.uk < >>>>> firedrake-bounces(a)imperial.ac.uk> on behalf of Colin Cotter < >>>>> colin.cotter(a)imperial.ac.uk> >>>>> *Sent:* Sunday, June 26, 2016 11:26 AM >>>>> *To:* firedrake >>>>> *Subject:* Re: [firedrake] upwind example remark; extension to CN in >>>>> time >>>>> >>>>> Hi Onno, >>>>> In answer to your first question. Things are simplified in the >>>>> advection demo because we know which edges are upwind, which are downwind, >>>>> and which have no flow through them. If you wanted to generalise this, then >>>>> we would need a surface integral over the entire external boundary with a >>>>> switch that either gave the internal value of the tracer or the inflow >>>>> boundary condition, depending on the direction of u.n, just like we did for >>>>> the interior facets. >>>>> Instead, in this example, on the outflow boundary we just write an >>>>> integral involving the interior value, and on the inflow boundary we write >>>>> an integral setting the inflow values. >>>>> >>>>> all the best >>>>> -cjc >>>>> >>>>> On 25 June 2016 at 16:05, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >>>>> >>>>>> Hi FDs, >>>>>> >>>>>> >>>>>> (i) The upwind example is odd in that the real boundaries are treated >>>>>> >>>>>> in a special way rather than setting the outside value in >>>>>> >>>>>> the same numerical flux as anywhere else; >>>>>> >>>>>> my question is how this can be fixed? >>>>>> >>>>>> So no special terms at the in- and outflow, just specify >>>>>> >>>>>> the outside velocity used. This is imo the proper DG way not was is >>>>>> done >>>>>> >>>>>> now. >>>>>> >>>>>> >>>>>> (ii) Attached my attempt to do a time dependent advection >>>>>> >>>>>> with Crank Nicolson, which works but does not yet >>>>>> >>>>>> give the right answer, in part due to (i). >>>>>> >>>>>> >>>>>> [I don't understand why I have to make >>>>>> >>>>>> my theta variable that a constant but other wise it did not work.] >>>>>> >>>>>> Any suggestions, corrections, also on other silly things done by me? >>>>>> >>>>>> Next step is to extend to system with 3 equations; >>>>>> hence the few extra but unused variables. >>>>>> >>>>>> Thanks, from midnight Seoul in old style Korean guesthouse. >>>>>> >>>>>> Onno >>>>>> ------------------------------ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> http://www.imperial.ac.uk/people/colin.cotter >>>>> >>>>> www.cambridge.org/9781107663916 >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> http://www.imperial.ac.uk/people/colin.cotter >>> >>> www.cambridge.org/9781107663916 >>> >>> >>> >> >> >> -- >> http://www.imperial.ac.uk/people/colin.cotter >> >> www.cambridge.org/9781107663916 >> >> >> >

1 0

Re: [firedrake] upwind example remark; extension to CN in time
by Andrew McRae 27 Jun '16

27 Jun '16

Again, we do not use + and - on exterior facets. On 27 June 2016 at 11:29, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > Ah, that is: in our usual set-up at any face there is an orientation > chosen with one of the normals being called outside. > > That is arbitrary but once fixed it is known. > > In the interior that does not matter but at real boundaries > > the convention is always that the normal assigned is the > > normal pointing outside the domain. > > That is why at real boundaries one knows which sign convention > > concerns outside information. > > Otherwise how do you know whether to assign an outside the > > domain value to + or -? You would not know. > > > In my convention with - inside, the + side is then the given > > information from the outside. > > > ------------------------------ > *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of Colin Cotter <colin.cotter(a)imperial.ac.uk> > *Sent:* Monday, June 27, 2016 7:41 AM > *To:* firedrake > *Subject:* Re: [firedrake] upwind example remark; extension to CN in time > > Hi Onno, > But + and - are not on the inside or outside, they are just two > arbitrary sides. > > I'll look into why the code is crashing today hopefully, I have a phone > conference about admissions until 4pm. > > all the best > > --cjc > > On 27 June 2016 at 04:34, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > >> Hi Colin, >> >> >> I know that of course as that is how I loop in my own c or matlab >> >> programs! One loop over elements and one loop over the faces. >> >> >> I am just saying state in the documentation example >> >> that plus is on the inside when the normal is pointing outward, >> >> and minus on the outside. Just add one sentence. >> >> I usually tend to do that the other way around as >> >> it is the limit with -epsilon and epsilon positive that is on the inside >> (so minus not plus is my usual convention; it does not matter but define it >> also >> >> in the documentation example for clarity). >> >> >> * The one remaining issue in my code seems that FD does not like me to >> use D_(+) or D_(-) while D(+) and D(-) are allowed, with the one >> >> difference being that D is a TrailFunction >> >> and D_ (previous time step) a Function. >> >> I guess I don't understand that difference yet. >> >> >> Thanks for the UFL link. That will help. >> >> >> Best wishes, >> >> >> >> >> >> >> ------------------------------ >> *From:* firedrake-bounces(a)imperial.ac.uk < >> firedrake-bounces(a)imperial.ac.uk> on behalf of Colin Cotter < >> colin.cotter(a)imperial.ac.uk> >> *Sent:* Sunday, June 26, 2016 3:11 PM >> >> *To:* firedrake >> *Subject:* Re: [firedrake] upwind example remark; extension to CN in time >> >> Hi Onno, >> This is documented in the UFL manual (the plusses, minusses etc.). >> >> fenicsproject.org/pub/documents/*ufl*/*ufl*-user-*manual*/*ufl*-user- >> *manual*.pdf >> >> The reason for this notation is that UFL is written for a global domain, >> in particular for facets it is the union of all interior facets, and when >> surface integrals are done, the facets are visited one by one instead of >> the cells. This means that there needs to be an (arbitrary) labelling of + >> and - sides of each facet. The notation was originally invented to write >> down global inner products to analyse DG methods for elliptic problems, >> where it is completely standard. This notation was set out in >> Arnold, Douglas N., et al. "Unified analysis of discontinuous Galerkin >> methods for elliptic problems." *SIAM journal on numerical analysis* 39.5 >> (2002): 1749-1779. >> >> all the best >> --cjc >> >> On 26 June 2016 at 14:08, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >> >>> Sure I knew that. D+ is on the inside of a cell with n pointing outward >>> >>> unless I am blinded by being on the other side of the world. >>> >>> Bit unusual convention in the DG world. Usually minus is on the inside. >>> >>> But could it as such be defined in the write-up/documentation please? >>> >>> In any DG article the convention whatever it is gets defined. >>> >>> >>> ------------------------------ >>> *From:* firedrake-bounces(a)imperial.ac.uk < >>> firedrake-bounces(a)imperial.ac.uk> on behalf of Andrew McRae < >>> A.T.T.McRae(a)bath.ac.uk> >>> *Sent:* Sunday, June 26, 2016 12:40 PM >>> *To:* firedrake(a)imperial.ac.uk >>> >>> *Subject:* Re: [firedrake] upwind example remark; extension to CN in >>> time >>> >>> D+ and D- refer to the values either side of an interior facet between >>> two cells. >>> >>> On the boundary (exterior facets), there is no such ambiguity, so just D >>> is used. >>> >>> In the steady-state example on the website, this D enters the >>> left-hand-side integral over the outflow part of the boundary, while the >>> prescribed function D0 is used in the integral over the inflow part. >>> >>> "In general", you can write a term that contains both D and D0 and >>> 'picks the right one' depending on the sign of u.n (this is how the >>> interior facet integral works). Note that n always points *outwards* on >>> the exterior boundary facets. >>> >>> On 26 June 2016 at 12:24, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >>> >>>> The issue is that D_('+') (or D_('-')) is not defined but I don't >>>> understand why not, or how to fix it? >>>> >>>> >>>> ------------------------------ >>>> *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:* Sunday, June 26, 2016 12:21 PM >>>> >>>> *To:* firedrake >>>> *Subject:* Re: [firedrake] upwind example remark; extension to CN in >>>> time >>>> >>>> >>>> Yes that was my point indeed. >>>> >>>> To build any more advanced code upon this one, one >>>> >>>> would need to use an alternate approach entirely >>>> >>>> through the flux. >>>> >>>> That is why it may be useful to extend the >>>> >>>> example with two alternatives: the simple one shown >>>> >>>> and one flux-based only. >>>> >>>> >>>> By the way, in the attached I have L2=0 and thet=0; >>>> >>>> if I uncomment the actual L2 there is a complaint, >>>> >>>> even though they=0. >>>> >>>> Obviously I need this term for the general theta-scheme, >>>> >>>> including thet=0.5 (Crank-Nicolson). >>>> >>>> I am doing the above simple extensions to get used to FD! >>>> Small steps ... >>>> >>>> The example is ties such that value 1 advects into through the >>>> entire domain in the time set. >>>> ------------------------------ >>>> *From:* firedrake-bounces(a)imperial.ac.uk < >>>> firedrake-bounces(a)imperial.ac.uk> on behalf of Colin Cotter < >>>> colin.cotter(a)imperial.ac.uk> >>>> *Sent:* Sunday, June 26, 2016 11:26 AM >>>> *To:* firedrake >>>> *Subject:* Re: [firedrake] upwind example remark; extension to CN in >>>> time >>>> >>>> Hi Onno, >>>> In answer to your first question. Things are simplified in the >>>> advection demo because we know which edges are upwind, which are downwind, >>>> and which have no flow through them. If you wanted to generalise this, then >>>> we would need a surface integral over the entire external boundary with a >>>> switch that either gave the internal value of the tracer or the inflow >>>> boundary condition, depending on the direction of u.n, just like we did for >>>> the interior facets. >>>> Instead, in this example, on the outflow boundary we just write an >>>> integral involving the interior value, and on the inflow boundary we write >>>> an integral setting the inflow values. >>>> >>>> all the best >>>> -cjc >>>> >>>> On 25 June 2016 at 16:05, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >>>> >>>>> Hi FDs, >>>>> >>>>> >>>>> (i) The upwind example is odd in that the real boundaries are treated >>>>> >>>>> in a special way rather than setting the outside value in >>>>> >>>>> the same numerical flux as anywhere else; >>>>> >>>>> my question is how this can be fixed? >>>>> >>>>> So no special terms at the in- and outflow, just specify >>>>> >>>>> the outside velocity used. This is imo the proper DG way not was is >>>>> done >>>>> >>>>> now. >>>>> >>>>> >>>>> (ii) Attached my attempt to do a time dependent advection >>>>> >>>>> with Crank Nicolson, which works but does not yet >>>>> >>>>> give the right answer, in part due to (i). >>>>> >>>>> >>>>> [I don't understand why I have to make >>>>> >>>>> my theta variable that a constant but other wise it did not work.] >>>>> >>>>> Any suggestions, corrections, also on other silly things done by me? >>>>> >>>>> Next step is to extend to system with 3 equations; >>>>> hence the few extra but unused variables. >>>>> >>>>> Thanks, from midnight Seoul in old style Korean guesthouse. >>>>> >>>>> Onno >>>>> ------------------------------ >>>>> >>>> >>>> >>>> >>>> -- >>>> http://www.imperial.ac.uk/people/colin.cotter >>>> >>>> www.cambridge.org/9781107663916 >>>> >>>> >>>> >>> >> >> >> -- >> http://www.imperial.ac.uk/people/colin.cotter >> >> www.cambridge.org/9781107663916 >> >> >> > > > -- > http://www.imperial.ac.uk/people/colin.cotter > > www.cambridge.org/9781107663916 > > >

2 1

Re: [firedrake] upwind example remark; extension to CN in time
by Colin Cotter 27 Jun '16

27 Jun '16

Hi Onno, But + and - are not on the inside or outside, they are just two arbitrary sides. I'll look into why the code is crashing today hopefully, I have a phone conference about admissions until 4pm. all the best --cjc On 27 June 2016 at 04:34, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > Hi Colin, > > > I know that of course as that is how I loop in my own c or matlab > > programs! One loop over elements and one loop over the faces. > > > I am just saying state in the documentation example > > that plus is on the inside when the normal is pointing outward, > > and minus on the outside. Just add one sentence. > > I usually tend to do that the other way around as > > it is the limit with -epsilon and epsilon positive that is on the inside > (so minus not plus is my usual convention; it does not matter but define it > also > > in the documentation example for clarity). > > > * The one remaining issue in my code seems that FD does not like me to use > D_(+) or D_(-) while D(+) and D(-) are allowed, with the one > > difference being that D is a TrailFunction > > and D_ (previous time step) a Function. > > I guess I don't understand that difference yet. > > > Thanks for the UFL link. That will help. > > > Best wishes, > > > > > > > ------------------------------ > *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of Colin Cotter <colin.cotter(a)imperial.ac.uk> > *Sent:* Sunday, June 26, 2016 3:11 PM > > *To:* firedrake > *Subject:* Re: [firedrake] upwind example remark; extension to CN in time > > Hi Onno, > This is documented in the UFL manual (the plusses, minusses etc.). > > fenicsproject.org/pub/documents/*ufl*/*ufl*-user-*manual*/*ufl*-user- > *manual*.pdf > > The reason for this notation is that UFL is written for a global domain, > in particular for facets it is the union of all interior facets, and when > surface integrals are done, the facets are visited one by one instead of > the cells. This means that there needs to be an (arbitrary) labelling of + > and - sides of each facet. The notation was originally invented to write > down global inner products to analyse DG methods for elliptic problems, > where it is completely standard. This notation was set out in > Arnold, Douglas N., et al. "Unified analysis of discontinuous Galerkin > methods for elliptic problems." *SIAM journal on numerical analysis* 39.5 > (2002): 1749-1779. > > all the best > --cjc > > On 26 June 2016 at 14:08, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > >> Sure I knew that. D+ is on the inside of a cell with n pointing outward >> >> unless I am blinded by being on the other side of the world. >> >> Bit unusual convention in the DG world. Usually minus is on the inside. >> >> But could it as such be defined in the write-up/documentation please? >> >> In any DG article the convention whatever it is gets defined. >> >> >> ------------------------------ >> *From:* firedrake-bounces(a)imperial.ac.uk < >> firedrake-bounces(a)imperial.ac.uk> on behalf of Andrew McRae < >> A.T.T.McRae(a)bath.ac.uk> >> *Sent:* Sunday, June 26, 2016 12:40 PM >> *To:* firedrake(a)imperial.ac.uk >> *Subject:* Re: [firedrake] upwind example remark; extension to CN in time >> >> D+ and D- refer to the values either side of an interior facet between >> two cells. >> >> On the boundary (exterior facets), there is no such ambiguity, so just D >> is used. >> >> In the steady-state example on the website, this D enters the >> left-hand-side integral over the outflow part of the boundary, while the >> prescribed function D0 is used in the integral over the inflow part. >> >> "In general", you can write a term that contains both D and D0 and 'picks >> the right one' depending on the sign of u.n (this is how the interior facet >> integral works). Note that n always points *outwards* on the exterior >> boundary facets. >> >> On 26 June 2016 at 12:24, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >> >>> The issue is that D_('+') (or D_('-')) is not defined but I don't >>> understand why not, or how to fix it? >>> >>> >>> ------------------------------ >>> *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:* Sunday, June 26, 2016 12:21 PM >>> >>> *To:* firedrake >>> *Subject:* Re: [firedrake] upwind example remark; extension to CN in >>> time >>> >>> >>> Yes that was my point indeed. >>> >>> To build any more advanced code upon this one, one >>> >>> would need to use an alternate approach entirely >>> >>> through the flux. >>> >>> That is why it may be useful to extend the >>> >>> example with two alternatives: the simple one shown >>> >>> and one flux-based only. >>> >>> >>> By the way, in the attached I have L2=0 and thet=0; >>> >>> if I uncomment the actual L2 there is a complaint, >>> >>> even though they=0. >>> >>> Obviously I need this term for the general theta-scheme, >>> >>> including thet=0.5 (Crank-Nicolson). >>> >>> I am doing the above simple extensions to get used to FD! >>> Small steps ... >>> >>> The example is ties such that value 1 advects into through the >>> entire domain in the time set. >>> ------------------------------ >>> *From:* firedrake-bounces(a)imperial.ac.uk < >>> firedrake-bounces(a)imperial.ac.uk> on behalf of Colin Cotter < >>> colin.cotter(a)imperial.ac.uk> >>> *Sent:* Sunday, June 26, 2016 11:26 AM >>> *To:* firedrake >>> *Subject:* Re: [firedrake] upwind example remark; extension to CN in >>> time >>> >>> Hi Onno, >>> In answer to your first question. Things are simplified in the >>> advection demo because we know which edges are upwind, which are downwind, >>> and which have no flow through them. If you wanted to generalise this, then >>> we would need a surface integral over the entire external boundary with a >>> switch that either gave the internal value of the tracer or the inflow >>> boundary condition, depending on the direction of u.n, just like we did for >>> the interior facets. >>> Instead, in this example, on the outflow boundary we just write an >>> integral involving the interior value, and on the inflow boundary we write >>> an integral setting the inflow values. >>> >>> all the best >>> -cjc >>> >>> On 25 June 2016 at 16:05, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >>> >>>> Hi FDs, >>>> >>>> >>>> (i) The upwind example is odd in that the real boundaries are treated >>>> >>>> in a special way rather than setting the outside value in >>>> >>>> the same numerical flux as anywhere else; >>>> >>>> my question is how this can be fixed? >>>> >>>> So no special terms at the in- and outflow, just specify >>>> >>>> the outside velocity used. This is imo the proper DG way not was is done >>>> >>>> now. >>>> >>>> >>>> (ii) Attached my attempt to do a time dependent advection >>>> >>>> with Crank Nicolson, which works but does not yet >>>> >>>> give the right answer, in part due to (i). >>>> >>>> >>>> [I don't understand why I have to make >>>> >>>> my theta variable that a constant but other wise it did not work.] >>>> >>>> Any suggestions, corrections, also on other silly things done by me? >>>> >>>> Next step is to extend to system with 3 equations; >>>> hence the few extra but unused variables. >>>> >>>> Thanks, from midnight Seoul in old style Korean guesthouse. >>>> >>>> Onno >>>> ------------------------------ >>>> >>> >>> >>> >>> -- >>> http://www.imperial.ac.uk/people/colin.cotter >>> >>> www.cambridge.org/9781107663916 >>> >>> >>> >> > > > -- > http://www.imperial.ac.uk/people/colin.cotter > > www.cambridge.org/9781107663916 > > > -- http://www.imperial.ac.uk/people/colin.cotter www.cambridge.org/9781107663916

2 1

Re: [firedrake] upwind example remark; extension to CN in time
by Colin Cotter 27 Jun '16

27 Jun '16

Hi Onno, This is documented in the UFL manual (the plusses, minusses etc.). fenicsproject.org/pub/documents/*ufl*/*ufl*-user-*manual*/*ufl*-user- *manual*.pdf The reason for this notation is that UFL is written for a global domain, in particular for facets it is the union of all interior facets, and when surface integrals are done, the facets are visited one by one instead of the cells. This means that there needs to be an (arbitrary) labelling of + and - sides of each facet. The notation was originally invented to write down global inner products to analyse DG methods for elliptic problems, where it is completely standard. This notation was set out in Arnold, Douglas N., et al. "Unified analysis of discontinuous Galerkin methods for elliptic problems." *SIAM journal on numerical analysis* 39.5 (2002): 1749-1779. all the best --cjc On 26 June 2016 at 14:08, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > Sure I knew that. D+ is on the inside of a cell with n pointing outward > > unless I am blinded by being on the other side of the world. > > Bit unusual convention in the DG world. Usually minus is on the inside. > > But could it as such be defined in the write-up/documentation please? > > In any DG article the convention whatever it is gets defined. > > > ------------------------------ > *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of Andrew McRae <A.T.T.McRae(a)bath.ac.uk> > *Sent:* Sunday, June 26, 2016 12:40 PM > *To:* firedrake(a)imperial.ac.uk > *Subject:* Re: [firedrake] upwind example remark; extension to CN in time > > D+ and D- refer to the values either side of an interior facet between two > cells. > > On the boundary (exterior facets), there is no such ambiguity, so just D > is used. > > In the steady-state example on the website, this D enters the > left-hand-side integral over the outflow part of the boundary, while the > prescribed function D0 is used in the integral over the inflow part. > > "In general", you can write a term that contains both D and D0 and 'picks > the right one' depending on the sign of u.n (this is how the interior facet > integral works). Note that n always points *outwards* on the exterior > boundary facets. > > On 26 June 2016 at 12:24, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > >> The issue is that D_('+') (or D_('-')) is not defined but I don't >> understand why not, or how to fix it? >> >> >> ------------------------------ >> *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:* Sunday, June 26, 2016 12:21 PM >> >> *To:* firedrake >> *Subject:* Re: [firedrake] upwind example remark; extension to CN in time >> >> >> Yes that was my point indeed. >> >> To build any more advanced code upon this one, one >> >> would need to use an alternate approach entirely >> >> through the flux. >> >> That is why it may be useful to extend the >> >> example with two alternatives: the simple one shown >> >> and one flux-based only. >> >> >> By the way, in the attached I have L2=0 and thet=0; >> >> if I uncomment the actual L2 there is a complaint, >> >> even though they=0. >> >> Obviously I need this term for the general theta-scheme, >> >> including thet=0.5 (Crank-Nicolson). >> >> I am doing the above simple extensions to get used to FD! >> Small steps ... >> >> The example is ties such that value 1 advects into through the >> entire domain in the time set. >> ------------------------------ >> *From:* firedrake-bounces(a)imperial.ac.uk < >> firedrake-bounces(a)imperial.ac.uk> on behalf of Colin Cotter < >> colin.cotter(a)imperial.ac.uk> >> *Sent:* Sunday, June 26, 2016 11:26 AM >> *To:* firedrake >> *Subject:* Re: [firedrake] upwind example remark; extension to CN in time >> >> Hi Onno, >> In answer to your first question. Things are simplified in the >> advection demo because we know which edges are upwind, which are downwind, >> and which have no flow through them. If you wanted to generalise this, then >> we would need a surface integral over the entire external boundary with a >> switch that either gave the internal value of the tracer or the inflow >> boundary condition, depending on the direction of u.n, just like we did for >> the interior facets. >> Instead, in this example, on the outflow boundary we just write an >> integral involving the interior value, and on the inflow boundary we write >> an integral setting the inflow values. >> >> all the best >> -cjc >> >> On 25 June 2016 at 16:05, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: >> >>> Hi FDs, >>> >>> >>> (i) The upwind example is odd in that the real boundaries are treated >>> >>> in a special way rather than setting the outside value in >>> >>> the same numerical flux as anywhere else; >>> >>> my question is how this can be fixed? >>> >>> So no special terms at the in- and outflow, just specify >>> >>> the outside velocity used. This is imo the proper DG way not was is done >>> >>> now. >>> >>> >>> (ii) Attached my attempt to do a time dependent advection >>> >>> with Crank Nicolson, which works but does not yet >>> >>> give the right answer, in part due to (i). >>> >>> >>> [I don't understand why I have to make >>> >>> my theta variable that a constant but other wise it did not work.] >>> >>> Any suggestions, corrections, also on other silly things done by me? >>> >>> Next step is to extend to system with 3 equations; >>> hence the few extra but unused variables. >>> >>> Thanks, from midnight Seoul in old style Korean guesthouse. >>> >>> Onno >>> ------------------------------ >>> >> >> >> >> -- >> http://www.imperial.ac.uk/people/colin.cotter >> >> www.cambridge.org/9781107663916 >> >> >> > -- http://www.imperial.ac.uk/people/colin.cotter www.cambridge.org/9781107663916

2 1

Stochastic differential equations
by Angwenyi David 26 Jun '16

26 Jun '16

Dear all, Is it possible to solve pdes driven by some noise using Firedrake? For example, see equation 3.2 in the attachment whose discretisation yields a system 3.3 and 3.4, where dW(t):=sqrt(dt)N(0,Identity). My other related concern is whether It is possible to implement, say, A Kalman filter with equation 3.2 as model equation on Firedrake. Thanks in advance. Angwenyi David

2 2

Re: [firedrake] upwind example remark; extension to CN in time
by Andrew McRae 26 Jun '16

26 Jun '16

D+ and D- refer to the values either side of an interior facet between two cells. On the boundary (exterior facets), there is no such ambiguity, so just D is used. In the steady-state example on the website, this D enters the left-hand-side integral over the outflow part of the boundary, while the prescribed function D0 is used in the integral over the inflow part. "In general", you can write a term that contains both D and D0 and 'picks the right one' depending on the sign of u.n (this is how the interior facet integral works). Note that n always points *outwards* on the exterior boundary facets. On 26 June 2016 at 12:24, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > The issue is that D_('+') (or D_('-')) is not defined but I don't > understand why not, or how to fix it? > > > ------------------------------ > *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:* Sunday, June 26, 2016 12:21 PM > > *To:* firedrake > *Subject:* Re: [firedrake] upwind example remark; extension to CN in time > > > Yes that was my point indeed. > > To build any more advanced code upon this one, one > > would need to use an alternate approach entirely > > through the flux. > > That is why it may be useful to extend the > > example with two alternatives: the simple one shown > > and one flux-based only. > > > By the way, in the attached I have L2=0 and thet=0; > > if I uncomment the actual L2 there is a complaint, > > even though they=0. > > Obviously I need this term for the general theta-scheme, > > including thet=0.5 (Crank-Nicolson). > > I am doing the above simple extensions to get used to FD! > Small steps ... > > The example is ties such that value 1 advects into through the > entire domain in the time set. > ------------------------------ > *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of Colin Cotter <colin.cotter(a)imperial.ac.uk> > *Sent:* Sunday, June 26, 2016 11:26 AM > *To:* firedrake > *Subject:* Re: [firedrake] upwind example remark; extension to CN in time > > Hi Onno, > In answer to your first question. Things are simplified in the advection > demo because we know which edges are upwind, which are downwind, and which > have no flow through them. If you wanted to generalise this, then we would > need a surface integral over the entire external boundary with a switch > that either gave the internal value of the tracer or the inflow boundary > condition, depending on the direction of u.n, just like we did for the > interior facets. > Instead, in this example, on the outflow boundary we just write an > integral involving the interior value, and on the inflow boundary we write > an integral setting the inflow values. > > all the best > -cjc > > On 25 June 2016 at 16:05, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > >> Hi FDs, >> >> >> (i) The upwind example is odd in that the real boundaries are treated >> >> in a special way rather than setting the outside value in >> >> the same numerical flux as anywhere else; >> >> my question is how this can be fixed? >> >> So no special terms at the in- and outflow, just specify >> >> the outside velocity used. This is imo the proper DG way not was is done >> >> now. >> >> >> (ii) Attached my attempt to do a time dependent advection >> >> with Crank Nicolson, which works but does not yet >> >> give the right answer, in part due to (i). >> >> >> [I don't understand why I have to make >> >> my theta variable that a constant but other wise it did not work.] >> >> Any suggestions, corrections, also on other silly things done by me? >> >> Next step is to extend to system with 3 equations; >> hence the few extra but unused variables. >> >> Thanks, from midnight Seoul in old style Korean guesthouse. >> >> Onno >> ------------------------------ >> > > > > -- > http://www.imperial.ac.uk/people/colin.cotter > > www.cambridge.org/9781107663916 > > >

2 1

Re: [firedrake] upwind example remark; extension to CN in time
by Colin Cotter 26 Jun '16

26 Jun '16

Hi Onno, In answer to your first question. Things are simplified in the advection demo because we know which edges are upwind, which are downwind, and which have no flow through them. If you wanted to generalise this, then we would need a surface integral over the entire external boundary with a switch that either gave the internal value of the tracer or the inflow boundary condition, depending on the direction of u.n, just like we did for the interior facets. Instead, in this example, on the outflow boundary we just write an integral involving the interior value, and on the inflow boundary we write an integral setting the inflow values. all the best -cjc On 25 June 2016 at 16:05, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > Hi FDs, > > > (i) The upwind example is odd in that the real boundaries are treated > > in a special way rather than setting the outside value in > > the same numerical flux as anywhere else; > > my question is how this can be fixed? > > So no special terms at the in- and outflow, just specify > > the outside velocity used. This is imo the proper DG way not was is done > > now. > > > (ii) Attached my attempt to do a time dependent advection > > with Crank Nicolson, which works but does not yet > > give the right answer, in part due to (i). > > > [I don't understand why I have to make > > my theta variable that a constant but other wise it did not work.] > > Any suggestions, corrections, also on other silly things done by me? > > Next step is to extend to system with 3 equations; > hence the few extra but unused variables. > > Thanks, from midnight Seoul in old style Korean guesthouse. > > Onno > ------------------------------ > -- http://www.imperial.ac.uk/people/colin.cotter www.cambridge.org/9781107663916

2 2

Re: [firedrake] upwind example remark; extension to CN in time
by Colin Cotter 26 Jun '16

26 Jun '16

Onno: please can you explain what you don't like about the output? all the best --cjc On 26 June 2016 at 00:35, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > Colin: I know as I was comparing different theta's! > > Francis: Oh I see that it does not allow to attach the mesh file to the > email. Odd. > I attach the base file instead. I know it is a rectangle I > assure you it will be changed to a 4-snaked channel. > > ------------------------------ > *From:* firedrake-bounces(a)imperial.ac.uk <firedrake-bounces(a)imperial.ac.uk> > on behalf of Colin Cotter <colin.cotter(a)imperial.ac.uk> > *Sent:* Saturday, June 25, 2016 9:25 PM > *To:* firedrake > *Subject:* Re: [firedrake] upwind example remark; extension to CN in time > > Hi Onno, > Did you see that you set theta to 0.0? If you want CN then it should be > 0.5? > > cheers > --cjc > > On 25 June 2016 at 16:05, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > >> Hi FDs, >> >> >> (i) The upwind example is odd in that the real boundaries are treated >> >> in a special way rather than setting the outside value in >> >> the same numerical flux as anywhere else; >> >> my question is how this can be fixed? >> >> So no special terms at the in- and outflow, just specify >> >> the outside velocity used. This is imo the proper DG way not was is done >> >> now. >> >> >> (ii) Attached my attempt to do a time dependent advection >> >> with Crank Nicolson, which works but does not yet >> >> give the right answer, in part due to (i). >> >> >> [I don't understand why I have to make >> >> my theta variable that a constant but other wise it did not work.] >> >> Any suggestions, corrections, also on other silly things done by me? >> >> Next step is to extend to system with 3 equations; >> hence the few extra but unused variables. >> >> Thanks, from midnight Seoul in old style Korean guesthouse. >> >> Onno >> ------------------------------ >> > > > > -- > http://www.imperial.ac.uk/people/colin.cotter > > www.cambridge.org/9781107663916 > > > -- http://www.imperial.ac.uk/people/colin.cotter www.cambridge.org/9781107663916

1 0

Re: [firedrake] upwind example remark; extension to CN in time
by Colin Cotter 26 Jun '16

26 Jun '16

Hi Onno, Did you see that you set theta to 0.0? If you want CN then it should be 0.5? cheers --cjc On 25 June 2016 at 16:05, Onno Bokhove <O.Bokhove(a)leeds.ac.uk> wrote: > Hi FDs, > > > (i) The upwind example is odd in that the real boundaries are treated > > in a special way rather than setting the outside value in > > the same numerical flux as anywhere else; > > my question is how this can be fixed? > > So no special terms at the in- and outflow, just specify > > the outside velocity used. This is imo the proper DG way not was is done > > now. > > > (ii) Attached my attempt to do a time dependent advection > > with Crank Nicolson, which works but does not yet > > give the right answer, in part due to (i). > > > [I don't understand why I have to make > > my theta variable that a constant but other wise it did not work.] > > Any suggestions, corrections, also on other silly things done by me? > > Next step is to extend to system with 3 equations; > hence the few extra but unused variables. > > Thanks, from midnight Seoul in old style Korean guesthouse. > > Onno > ------------------------------ > -- http://www.imperial.ac.uk/people/colin.cotter www.cambridge.org/9781107663916

2 1