April 2016 - firedrake - imperial.ac.uk

Re: [firedrake] Laplace equation on subdomain
by David Ham 24 May '16

24 May '16

Well the following reproduces the reported error for me: from firedrake import * m = UnitSquareMesh(2, 2) fs = FunctionSpace(m, "CG", 1) v = TestFunction(fs) assemble(v*dS) On Tue, 26 Apr 2016 at 21:27 Andrew McRae <A.T.T.McRae(a)bath.ac.uk> wrote: > 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 >>>>>> >>>>>

2 2

Converting FENICS code to Firedrake (iterations over mesh cells)
by George Ovchinnikov 03 May '16

03 May '16

Hi, I have the following code, which solves Poisson problem and prints solution in a cell and it neighbours also building cells adjacency matrix which is needed later on. The solving part maps to firedrake just fine, but I'm unsure about what to do with loops over cells and their neighbours. Here the code: u = TrialFunction(V) v = TestFunction(V) f = Constant(1) a = inner(nabla_grad(u), nabla_grad(v))*dx L = f*v*dx # Compute solution u = Function(V) solve(a == L, u, bcs) tdim = mesh.topology().dim() mesh.init(tdim - 1, tdim) cell_neighbors = {cell.index(): sum((filter(lambda ci: ci != cell.index(), facet.entities(tdim)) for facet in facets(cell)), []) for cell in cells(mesh)} print cell_neighbors print mesh.cells() for cell in cells(mesh): point = cell.midpoint() #print cell.index(), list(cells(mesh))[cell_neighbors[cell.index()][0]] nhs = [u(Cell(mesh, cx).midpoint()) for cx in cell_neighbors[cell.index()]] print u(point), nhs Sincerely, George

3 2

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

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