- firedrake - imperial.ac.uk

Re: [firedrake] REXI time stepping in Firedrake
by Colin Cotter 01 May '16

01 May '16

Hi Martin, I discussed this complex number issue with Terry Haut a while ago. He has an equivalent formulation that stays entirely in real numbers - this is because the complex values appear as conjugate pairs. So, it's probably easiest to move to this real-only formulation. By the way, the Coriolis term does make a big difference to how things are solved, I think that it will only be possible to efficiently solve this system using hybridisation techniques: this was the foundation of the proposal that we put in to NERC with Beth in January. To answer your other questions: we are converging towards a Firedrake dynamical core code, this is being developed on github: https://github.com/firedrakeproject/dcore but things are not really ready for integration with REXI yet, we still need to demonstrate that the basic discretisation works for 3D on the sphere. We have a plan to implement a multigrid solver for the the REXI scheme for FEM shallow water, and then develop an APINT scheme using Firedrake for shallow water on the sphere with Jemma, we should probably discuss to make sure that we don't tread on each other's toes. all the best --cjc On 30 April 2016 at 07:35, Martin SCHREIBER <M.Schreiber(a)exeter.ac.uk> wrote: > Dear Firedrakers, > > I discussed yesterday with Andrew if Firedrake can be (ab)used to solve > PDEs with a non-traditional time stepping method (we call it REXI) and > he suggested me to drop an Email to this mailing list. > (@David/Colin: It's related to our parallelization-in-time work). > > Let L be the linear operator of the SWE on the sphere in advective form > including the average height (by putting the perturbation into the > non-linear part). L also contains the longitude-varying Coriolis term, > but this shouldn't make a big difference here. > > As one building block of the new time stepping method we like to solve > the SoEs given by > (\alpha - L) U = U0 > with \alpha a complex shifted pole creating a non-singular SoE and U0 > the DoFs to solve for. > > I don't see any problem to write this in weak formulation as it is > required in Firedrake. > > Now the following questions arise: > > * Is Firedrake able to assemble and solve these system of equations with > the complex value \alpha? > It's only important to keep the real values of "U". The imaginary > values of U are not important if that's of any help. > > * If not, is Firedrake still able to solve a reformulation which would > have a 6x6 linear operator instead of a 3x3 and 6 DoFs (3 pseudo DoFs) > per cell? (Basically reformulating the SoE with real values instead of > complex ones). > > * Is there any Firedrake code publicly available with the GungHo FEM > dyn-core on the sphere with a C-grid? > > * A question related to possible future work: Is Firedrake supporting > Semi-Lagrangian methods efficiently? > > Cheers, > > Martin > > > -- > Dr. rer.-nat. Martin Schreiber > Lecturer, proleptic > Scientific and High-Performance Computing > University of Exeter > > College of Engineering, Mathematics and Physical Sciences > Harrison Building, Room 319, North Park Road, Exeter, EX4 4QF > > _______________________________________________ > firedrake mailing list > firedrake(a)imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/firedrake > -- http://www.imperial.ac.uk/people/colin.cotter www.cambridge.org/9781107663916

4 5

Re: [firedrake] REXI time stepping in Firedrake
by Andrew McRae 01 May '16

01 May '16

To rephrase that, the bigger pain is that Firedrake/FEniCS don't natively support complex data types. PETSc *already does* support complex data types, but with the annoyance that it has to be compiled separately for complex mode. On 1 May 2016 at 08:34, Colin Cotter <colin.cotter(a)imperial.ac.uk> wrote: > Hi Francis, > This was a specific thing about the formulation of rational > approximation of exponentials in the following paper: > http://arxiv.org/abs/1012.3196 > > Complex numbers are a pain because PETSc must be separately compiled with > complex data types. A possible workaround in current Firedrake/Fenics is to > have separate variables for real and imaginary parts and reinterpret the > problem as a real one of twice the size (although this limits the solvers > that can be used). > all the best > --cjc > > On 30 April 2016 at 21:14, Francis Poulin <fpoulin(a)uwaterloo.ca> wrote: > >> Hello Colin, >> >> As a bit of an aside, is there somewhere I can read more about the >> "complex number issue" that you discussed with Terry Haut? >> >> I ask because I have been trying to develop code in FEniCS to compute the >> linear stability characteristics in different models, i.e. QG, SW and >> whatever else I can muster. I have had success using the direct solver. >> Unfortunately, the way the problem is formulated I want to find the >> eigenvalue with the largest imaginary part. as I'm sure you already know, >> the imaginary numbers in PETSc and SLEPc are not part of the default FEniCS >> package, or so I've been told. This seems to suggest that I need to use a >> direct solver, which is problematic when I want to solve 2D eigenvalue >> problems. I wonder whether the complex number issue you mentioned might >> help me to reformulate it in such a way that the eigenvalue I want is real, >> which FEniCS can solve? >> >> I would be very happy to do all of this in firedrake but I have not seen >> any eigenvalue examples and have heard this is on the wish list, but I am >> sure you guys have a long wish list. If there is anything I can do to help >> in testing this I would be happy to. >> >> Best regards, >> Francis >> >> >> >> ------------------ >> Francis Poulin >> Associate Professor >> Department of Applied Mathematics >> University of Waterloo >> >> email: fpoulin(a)uwaterloo.ca >> Web: https://uwaterloo.ca/poulin-research-group/ >> Telephone: +1 519 888 4567 x32637 >> >> ------------------------------ >> *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, April 30, 2016 3:40 PM >> *To:* firedrake >> *Subject:* Re: [firedrake] REXI time stepping in Firedrake >> >> Hi Martin, >> I discussed this complex number issue with Terry Haut a while ago. He >> has an equivalent formulation that stays entirely in real numbers - this is >> because the complex values appear as conjugate pairs. So, it's probably >> easiest to move to this real-only formulation. >> >> By the way, the Coriolis term does make a big difference to how things >> are solved, I think that it will only be possible to efficiently solve this >> system using hybridisation techniques: this was the foundation of the >> proposal that we put in to NERC with Beth in January. >> >> To answer your other questions: we are converging towards a Firedrake >> dynamical core code, this is being developed on github: >> https://github.com/firedrakeproject/dcore >> but things are not really ready for integration with REXI yet, we still >> need to demonstrate that the basic discretisation works for 3D on the >> sphere. >> >> We have a plan to implement a multigrid solver for the the REXI scheme >> for FEM shallow water, and then develop an APINT scheme using Firedrake for >> shallow water on the sphere with Jemma, we should probably discuss to make >> sure that we don't tread on each other's toes. >> >> all the best >> --cjc >> >> On 30 April 2016 at 07:35, Martin SCHREIBER <M.Schreiber(a)exeter.ac.uk> >> wrote: >> >>> Dear Firedrakers, >>> >>> I discussed yesterday with Andrew if Firedrake can be (ab)used to solve >>> PDEs with a non-traditional time stepping method (we call it REXI) and >>> he suggested me to drop an Email to this mailing list. >>> (@David/Colin: It's related to our parallelization-in-time work). >>> >>> Let L be the linear operator of the SWE on the sphere in advective form >>> including the average height (by putting the perturbation into the >>> non-linear part). L also contains the longitude-varying Coriolis term, >>> but this shouldn't make a big difference here. >>> >>> As one building block of the new time stepping method we like to solve >>> the SoEs given by >>> (\alpha - L) U = U0 >>> with \alpha a complex shifted pole creating a non-singular SoE and U0 >>> the DoFs to solve for. >>> >>> I don't see any problem to write this in weak formulation as it is >>> required in Firedrake. >>> >>> Now the following questions arise: >>> >>> * Is Firedrake able to assemble and solve these system of equations with >>> the complex value \alpha? >>> It's only important to keep the real values of "U". The imaginary >>> values of U are not important if that's of any help. >>> >>> * If not, is Firedrake still able to solve a reformulation which would >>> have a 6x6 linear operator instead of a 3x3 and 6 DoFs (3 pseudo DoFs) >>> per cell? (Basically reformulating the SoE with real values instead of >>> complex ones). >>> >>> * Is there any Firedrake code publicly available with the GungHo FEM >>> dyn-core on the sphere with a C-grid? >>> >>> * A question related to possible future work: Is Firedrake supporting >>> Semi-Lagrangian methods efficiently? >>> >>> Cheers, >>> >>> Martin >>> >>> >>> -- >>> Dr. rer.-nat. Martin Schreiber >>> Lecturer, proleptic >>> Scientific and High-Performance Computing >>> University of Exeter >>> >>> College of Engineering, Mathematics and Physical Sciences >>> Harrison Building, Room 319, North Park Road, Exeter, EX4 4QF >>> >>> _______________________________________________ >>> firedrake mailing list >>> firedrake(a)imperial.ac.uk >>> https://mailman.ic.ac.uk/mailman/listinfo/firedrake >>> >> >> >> >> -- >> 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] REXI time stepping in Firedrake
by Colin Cotter 01 May '16

01 May '16

Hi Francis, This was a specific thing about the formulation of rational approximation of exponentials in the following paper: http://arxiv.org/abs/1012.3196 Complex numbers are a pain because PETSc must be separately compiled with complex data types. A possible workaround in current Firedrake/Fenics is to have separate variables for real and imaginary parts and reinterpret the problem as a real one of twice the size (although this limits the solvers that can be used). all the best --cjc On 30 April 2016 at 21:14, Francis Poulin <fpoulin(a)uwaterloo.ca> wrote: > Hello Colin, > > As a bit of an aside, is there somewhere I can read more about the > "complex number issue" that you discussed with Terry Haut? > > I ask because I have been trying to develop code in FEniCS to compute the > linear stability characteristics in different models, i.e. QG, SW and > whatever else I can muster. I have had success using the direct solver. > Unfortunately, the way the problem is formulated I want to find the > eigenvalue with the largest imaginary part. as I'm sure you already know, > the imaginary numbers in PETSc and SLEPc are not part of the default FEniCS > package, or so I've been told. This seems to suggest that I need to use a > direct solver, which is problematic when I want to solve 2D eigenvalue > problems. I wonder whether the complex number issue you mentioned might > help me to reformulate it in such a way that the eigenvalue I want is real, > which FEniCS can solve? > > I would be very happy to do all of this in firedrake but I have not seen > any eigenvalue examples and have heard this is on the wish list, but I am > sure you guys have a long wish list. If there is anything I can do to help > in testing this I would be happy to. > > Best regards, > Francis > > > > ------------------ > Francis Poulin > Associate Professor > Department of Applied Mathematics > University of Waterloo > > email: fpoulin(a)uwaterloo.ca > Web: https://uwaterloo.ca/poulin-research-group/ > Telephone: +1 519 888 4567 x32637 > > ------------------------------ > *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, April 30, 2016 3:40 PM > *To:* firedrake > *Subject:* Re: [firedrake] REXI time stepping in Firedrake > > Hi Martin, > I discussed this complex number issue with Terry Haut a while ago. He > has an equivalent formulation that stays entirely in real numbers - this is > because the complex values appear as conjugate pairs. So, it's probably > easiest to move to this real-only formulation. > > By the way, the Coriolis term does make a big difference to how things are > solved, I think that it will only be possible to efficiently solve this > system using hybridisation techniques: this was the foundation of the > proposal that we put in to NERC with Beth in January. > > To answer your other questions: we are converging towards a Firedrake > dynamical core code, this is being developed on github: > https://github.com/firedrakeproject/dcore > but things are not really ready for integration with REXI yet, we still > need to demonstrate that the basic discretisation works for 3D on the > sphere. > > We have a plan to implement a multigrid solver for the the REXI scheme for > FEM shallow water, and then develop an APINT scheme using Firedrake for > shallow water on the sphere with Jemma, we should probably discuss to make > sure that we don't tread on each other's toes. > > all the best > --cjc > > On 30 April 2016 at 07:35, Martin SCHREIBER <M.Schreiber(a)exeter.ac.uk> > wrote: > >> Dear Firedrakers, >> >> I discussed yesterday with Andrew if Firedrake can be (ab)used to solve >> PDEs with a non-traditional time stepping method (we call it REXI) and >> he suggested me to drop an Email to this mailing list. >> (@David/Colin: It's related to our parallelization-in-time work). >> >> Let L be the linear operator of the SWE on the sphere in advective form >> including the average height (by putting the perturbation into the >> non-linear part). L also contains the longitude-varying Coriolis term, >> but this shouldn't make a big difference here. >> >> As one building block of the new time stepping method we like to solve >> the SoEs given by >> (\alpha - L) U = U0 >> with \alpha a complex shifted pole creating a non-singular SoE and U0 >> the DoFs to solve for. >> >> I don't see any problem to write this in weak formulation as it is >> required in Firedrake. >> >> Now the following questions arise: >> >> * Is Firedrake able to assemble and solve these system of equations with >> the complex value \alpha? >> It's only important to keep the real values of "U". The imaginary >> values of U are not important if that's of any help. >> >> * If not, is Firedrake still able to solve a reformulation which would >> have a 6x6 linear operator instead of a 3x3 and 6 DoFs (3 pseudo DoFs) >> per cell? (Basically reformulating the SoE with real values instead of >> complex ones). >> >> * Is there any Firedrake code publicly available with the GungHo FEM >> dyn-core on the sphere with a C-grid? >> >> * A question related to possible future work: Is Firedrake supporting >> Semi-Lagrangian methods efficiently? >> >> Cheers, >> >> Martin >> >> >> -- >> Dr. rer.-nat. Martin Schreiber >> Lecturer, proleptic >> Scientific and High-Performance Computing >> University of Exeter >> >> College of Engineering, Mathematics and Physical Sciences >> Harrison Building, Room 319, North Park Road, Exeter, EX4 4QF >> >> _______________________________________________ >> firedrake mailing list >> firedrake(a)imperial.ac.uk >> https://mailman.ic.ac.uk/mailman/listinfo/firedrake >> > > > > -- > 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

REXI time stepping in Firedrake
by Martin SCHREIBER 30 Apr '16

30 Apr '16

Dear Firedrakers, I discussed yesterday with Andrew if Firedrake can be (ab)used to solve PDEs with a non-traditional time stepping method (we call it REXI) and he suggested me to drop an Email to this mailing list. (@David/Colin: It's related to our parallelization-in-time work). Let L be the linear operator of the SWE on the sphere in advective form including the average height (by putting the perturbation into the non-linear part). L also contains the longitude-varying Coriolis term, but this shouldn't make a big difference here. As one building block of the new time stepping method we like to solve the SoEs given by (\alpha - L) U = U0 with \alpha a complex shifted pole creating a non-singular SoE and U0 the DoFs to solve for. I don't see any problem to write this in weak formulation as it is required in Firedrake. Now the following questions arise: * Is Firedrake able to assemble and solve these system of equations with the complex value \alpha? It's only important to keep the real values of "U". The imaginary values of U are not important if that's of any help. * If not, is Firedrake still able to solve a reformulation which would have a 6x6 linear operator instead of a 3x3 and 6 DoFs (3 pseudo DoFs) per cell? (Basically reformulating the SoE with real values instead of complex ones). * Is there any Firedrake code publicly available with the GungHo FEM dyn-core on the sphere with a C-grid? * A question related to possible future work: Is Firedrake supporting Semi-Lagrangian methods efficiently? Cheers, Martin -- Dr. rer.-nat. Martin Schreiber Lecturer, proleptic Scientific and High-Performance Computing University of Exeter College of Engineering, Mathematics and Physical Sciences Harrison Building, Room 319, North Park Road, Exeter, EX4 4QF

1 0

Firedrake users: highlighting your research at FEniCS '16
by David Ham 28 Apr '16

28 Apr '16

Dear Firedrakers, FEniCS '16 is on at Simula in Oslo in mid May. I know that some of you are going, but many will not be. I will be taking a Firedrake applications poster to the workshop. This is an opportunity to highlight your work using Firedrake. I would hope to have information on as many Firedrake applications as possible. Even if you are presenting your application at FEniCS '16, I'd still like to highlight it on the poster. To have your application featured on the poster, I'll need the following information: 1. Title - this could be your package name or a (short) title describing your work. 2. Authors and institution. 3. At most two sentences describing what you are working on with Firedrake. Think press release rather than journal paper. 4. If at all possible, a single image which characterises your work. It should have a single line caption. Additionally, you could provide any of the following if you have them: A. Project logo B. Institutional logo(s) C. Project URL (which I will turn into a QR code). If you plan on submitting something, PLEASE RESPOND IMMEDIATELY to let me know you will be doing so. Please provide the data above by WEDNESDAY 4 MAY to enable me to make the poster and get it printed. Regards, David

2 1

Re: [firedrake] Question on absolute requirement of weak form formulation
by Colin Cotter 28 Apr '16

28 Apr '16

Dear Krishna, From the website: "Firedrake is an automated system for the portable solution of partial differential equations using the finite element method (FEM)." If you want to use the finite element method, you need to learn how to use weak forms, yes. Using OpenFOAM also requires knowledge of how discretisations work, just like Firedrake or any similar package. all the best --cjc On 28 April 2016 at 07:11, Gopalakrishnan, Krishnakumar < k.gopalakrishnan14(a)imperial.ac.uk> wrote: > Hello, > > > > I am a total newbie to firedrake. I am trying to solve a coupled > multiphysics system described by 4 PDEs & 1 algebraic equation. > > > > I am totally new to numerical PDE solving. I would like to avoid > formulating my problem in the weak-form if possible. People recommended > OpenFOAM to me, as the codes are written in nearly the same way they are > mathematically cast. > > > > However, walking through firedrake tutorials, I see that there is a need > for formulating the problem in weak-form. The truth is I don’t know how > to do this. Do I have to learn this art, or is there a workaround > recommended ? > > > > > > Krishna > -- http://www.imperial.ac.uk/people/colin.cotter www.cambridge.org/9781107663916

1 0

Question on absolute requirement of weak form formulation
by Gopalakrishnan, Krishnakumar 28 Apr '16

28 Apr '16

Hello, I am a total newbie to firedrake. I am trying to solve a coupled multiphysics system described by 4 PDEs & 1 algebraic equation. I am totally new to numerical PDE solving. I would like to avoid formulating my problem in the weak-form if possible. People recommended OpenFOAM to me, as the codes are written in nearly the same way they are mathematically cast. However, walking through firedrake tutorials, I see that there is a need for formulating the problem in weak-form. The truth is I don't know how to do this. Do I have to learn this art, or is there a workaround recommended ? Krishna

1 0

Firedrake installation stuck at petsc install
by Gopalakrishnan, Krishnakumar 27 Apr '16

27 Apr '16

Hello, I tried installing firedrake on my Ubuntu Wily Werewolf machine. I am using the setup script provided on the webpage. Everything goes fine, until it hit this stage, where the installation is currently stuck for the past one hour. 'Processing ./petsc Installing collected packages: petsc Running setup.py install for petsc ... \' Any idea what might be going wrong ? How do I recover from this situation ? Best Regards Krishna

3 2

Re: [firedrake] Laplace equation on subdomain
by Andrew McRae 26 Apr '16

26 Apr '16

I didn't think this was true, unless something changed "recently". I can't test right now, but I'm quite confident I used to use continuous functions in interior facet integrals on simplex meshes without needing a restriction. However, I recall being forced to use restrictions on extruded meshes; I never got to the bottom of why. Perhaps Miklós can comment (or state that my recollection is nonsense)? On 26 April 2016 at 21:12, David Ham <David.Ham(a)imperial.ac.uk> wrote: > Hi Tomasz, > > This is a subtlety of UFL. *All* arguments and coefficients in an interior > facet integral have to be "restricted". This even applies to ones which are > continuous and for which the "+" and "-" restrictions are therefore the > same. You can just arbitrarily decide to restrict the continuous things to > the plus side, or take avg() of the lack of symmetry offends your sense of > aesthetics. > > Regards, > > David > > On Tue, 26 Apr 2016 at 15:46 Tomasz Salwa [RPG] <mmtjs(a)leeds.ac.uk> wrote: > >> Hi, >> >> >> Previous problem continued. >> >> I have a working solver for separate subsystems in mixed function space >> now. I'd like to introduce the coupling terms at the interface, but they >> cause a UFL exception "Discontinuous type Argument must be restricted." >> >> Full code is here: https://bitbucket.org/mmtjs/lin_coupled_fd_2d >> >> >> <https://bitbucket.org/mmtjs/lin_coupled_fd_2d> >> >> The relevant part from lib/coupled_system.py is: >> >> ... >> >> # define the normal vector at the interface >> >> self.n = fd.FacetNormal(self.mesh) >> self.n_int = (self.B.I("+")*self.W.I("-") - >> self.B.I("-")*self.W.I("+"))*self.n("+") # btw how can write this to file >> to verify? >> >> ... >> >> # the second line causes exception (and later similar terms too) >> >> a_U = fd.dot( self.trial_s * self.B.I, self.v_s * self.B.I) * >> fd.dx \ >> + fd.dot( self.v_s, self.n_int ) * self.trial_f * >> fd.dS >> >> >> Regards, >> >> Tomasz >> >> >> >> ------------------------------ >> *From:* firedrake-bounces(a)imperial.ac.uk < >> firedrake-bounces(a)imperial.ac.uk> on behalf of Tomasz Salwa [RPG] < >> mmtjs(a)leeds.ac.uk> >> *Sent:* 21 April 2016 11:04 >> >> *To:* firedrake >> *Subject:* Re: [firedrake] Laplace equation on subdomain >> >> >> Cool, works now, dynamic case too. I'll do the same for the structural >> part. >> >> >> Cheers, >> >> Tomasz >> >> >> ------------------------------ >> *From:* firedrake-bounces(a)imperial.ac.uk < >> firedrake-bounces(a)imperial.ac.uk> on behalf of David Ham < >> David.Ham(a)imperial.ac.uk> >> *Sent:* 21 April 2016 09:38 >> *To:* firedrake >> *Subject:* Re: [firedrake] Laplace equation on subdomain >> Hi Tomasz, >> >> See the new pull request. In essence, the projection is not safe in the >> indicator function case. >> >> Regards, >> >> David >> >> On Wed, 20 Apr 2016 at 15:53 Tomasz Salwa [RPG] <mmtjs(a)leeds.ac.uk> >> wrote: >> >>> Hi David, >>> >>> >>> Thank you, now it converges properly. >>> >>> However, I noticed that the error depends on the mesh resolution beyond >>> the fluid subdomain, which I think should not be the case (at least when I >>> refine it in x direction). Perhaps the solution is ok, but the source is in >>> the way I impose the analytical one, or compute the error. Can you diagnose >>> this? >>> >>> Bitbucket's repo is updated. >>> >>> >>> Regards, >>> >>> Tomasz >>> >>> >>> ------------------------------ >>> *From:* firedrake-bounces(a)imperial.ac.uk < >>> firedrake-bounces(a)imperial.ac.uk> on behalf of David Ham < >>> David.Ham(a)imperial.ac.uk> >>> *Sent:* 20 April 2016 10:05 >>> >>> *To:* firedrake >>> *Subject:* Re: [firedrake] Laplace equation on subdomain >>> Hi Tomasz, >>> >>> I have just put in a pull request fixing your problem. In essence, you >>> were only applying half of the indicator function fix. In order to >>> correctly use indicator functions to solve problems over a subdomain, it is >>> necessary to *both* use the custom boundary condition to force the solution >>> in the rest of the domain to zero *and* multiply the integrands in your >>> forms by the indicator function. You were only doing the former and not the >>> latter. Making this fix causes the error to drop to 10^-5. I haven't done a >>> convergence test to check that the error converges at the right rate, but >>> you should really do so. >>> >>> Regards, >>> >>> David >>> >>> On Tue, 19 Apr 2016 at 11:52 Tomasz Salwa [RPG] <mmtjs(a)leeds.ac.uk> >>> wrote: >>> >>>> Hi David, >>>> >>>> >>>> Here's the code: >>>> >>>> https://bitbucket.org/mmtjs/laplace_extended_domain >>>> >>>> >>>> It's roughly the same as before, just with a gmsh-generated mesh. >>>> >>>> >>>> Regards, >>>> >>>> Tomasz >>>> >>>> >>>> ------------------------------ >>>> *From:* firedrake-bounces(a)imperial.ac.uk < >>>> firedrake-bounces(a)imperial.ac.uk> on behalf of David Ham < >>>> David.Ham(a)imperial.ac.uk> >>>> *Sent:* 19 April 2016 09:54 >>>> *To:* firedrake >>>> >>>> *Subject:* Re: [firedrake] Laplace equation on subdomain >>>> Hi Tomasz, >>>> >>>> Can you please post the code you are using for this (preferably by >>>> pointing us to a git repo we can clone). I can't diagnose what is going >>>> wrong just by looking at the visualisation, I'm afraid. >>>> >>>> Regards, >>>> >>>> David >>>> >>>> On Mon, 18 Apr 2016 at 12:12 Tomasz Salwa [RPG] <mmtjs(a)leeds.ac.uk> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I plotted the difference between analytical and numerical solutions >>>>> (see attached). It doesn't converge to the right solution with mesh >>>>> refinement. Is it possible that the Neumann BC is not applied at the >>>>> interface during the computation, although the extended Dirichlet BCs >>>>> enforce resulting zero solution beyond the fluid subdomain? >>>>> >>>>> Cheers, >>>>> Tomasz >>>>> >>>>> ________________________________________ >>>>> From: firedrake-bounces(a)imperial.ac.uk < >>>>> firedrake-bounces(a)imperial.ac.uk> on behalf of Lawrence Mitchell < >>>>> lawrence.mitchell(a)imperial.ac.uk> >>>>> Sent: 15 April 2016 16:00 >>>>> To: firedrake(a)imperial.ac.uk >>>>> Subject: Re: [firedrake] Laplace equation on subdomain >>>>> >>>>> > On 15 Apr 2016, at 15:54, Tomasz Salwa [RPG] <mmtjs(a)leeds.ac.uk> >>>>> wrote: >>>>> > >>>>> > Hi David, >>>>> > >>>>> > It works partially, i.e. the nodes beyond the fluid subdomain are >>>>> "turned off" now, but it looks like the interface is "smeared". I suspect >>>>> that the assembled matrix's entries involve also integration over elements >>>>> one layer beyond the subdomain boundary. Is it possible to exclude them? >>>>> >>>>> If you have neumann conditions on your subdomain boundary you've only >>>>> constrained the gradient of the solution. Therefore on the boundary nodes >>>>> you may have non-zero solution values. >>>>> >>>>> Because the domain you visualise in paraview extends outside the >>>>> subdomain you'll have (in 1D) something like: >>>>> >>>>> >>>>> ........ >>>>> \............ >>>>> ^ boundary node >>>>> >>>>> Note how the cell at the boundary has a non-zero coefficient value are >>>>> one end, but a zero value at the other (assuming piecewise liners). >>>>> Paraview will linearly interpolate this basis function when visualising, >>>>> which may be the artefact you're seeing. >>>>> >>>>> Can you construct an analytic solution and determine that you converge >>>>> at the correct rate as you refine the mesh? This is a safer test than >>>>> eyeballing the solution. >>>>> >>>>> Lawrence >>>>> >>>>

1 0

Re: [firedrake] parallelization
by Andrew McRae 26 Apr '16

26 Apr '16

Strange use of "optimal" :) There are some strong and weak scaling experiments in Section 6 of the Firedrake paper -- http://arxiv.org/abs/1501.01809 -- which may guide your cores-to-DOFs intuition. Best, Andrew On 26 April 2016 at 21:18, Francis Poulin <fpoulin(a)uwaterloo.ca> wrote: > Hello again, > > In case your curious, on my ubuntu machine with 2x8 cores I get, > approximately, > > np = 16 30 mins > np = 8 35 mins > np = 4 57 mins > np = 2 ?? > np = 1 ~4.5 hours > > I don't think I'll necessarily try np = 2 but it does seem that 8 probably > the optimal value for this case. I am sure that with higher resolution (or > a third dimension) the efficiency would improve but it's already looking > very good. > > Francis > > _______________________________________________ > firedrake mailing list > firedrake(a)imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/firedrake >

1 0