- firedrake - imperial.ac.uk

Crash in projection on ARCHER
by Eike Mueller 03 Apr '15

03 Apr '15

Dear firedrakers, I just updated all modules on ARCHER and tried to run my code there. However, I get the error below. Thanks, Eike Traceback (most recent call last): File "/work/n02/n02/eike//git_workspace/firedrake-helmholtzsolver/source/driver.py", line 619, in <module> main(parameter_filename) File "/work/n02/n02/eike//git_workspace/firedrake-helmholtzsolver/source/driver.py", line 585, in main expression) File "/work/n02/n02/eike//git_workspace/firedrake-helmholtzsolver/source/driver.py", line 400, in solve_matrixfree r_p.project(expression) File "/work/n02/n02/eike/git_workspace/firedrake/firedrake/function.py", line 146, in project return projection.project(b, self, *args, **kwargs) File "/work/n02/n02/eike/git_workspace/firedrake/firedrake/projection.py", line 94, in project form_compiler_parameters=form_compiler_parameters) File "/work/n02/n02/eike/git_workspace/firedrake/firedrake/solving.py", line 119, in solve _solve_varproblem(*args, **kwargs) File "/work/n02/n02/eike/git_workspace/firedrake/firedrake/solving.py", line 144, in _solve_varproblem solver.solve() File "<string>", line 2, in solve File "/work/n02/n02/eike/git_workspace/PyOP2/pyop2/profiling.py", line 197, in wrapper return f(*args, **kwargs) File "/work/n02/n02/eike/git_workspace/firedrake/firedrake/variational_solver.py", line 153, in solve self.snes.solve(None, v) File "SNES.pyx", line 516, in petsc4py.PETSc.SNES.solve (src/petsc4py.PETSc.c:158929) File "petscsnes.pxi", line 251, in petsc4py.PETSc.SNES_Function (src/petsc4py.PETSc.c:30207) File "/work/n02/n02/eike/git_workspace/firedrake/firedrake/solving_utils.py", line 170, in form_function with ctx._xs[lvl].dat.vec as v: IndexError: tuple index out of range

3 6

Fwd: New College regulations on Lectures start today
by David Ham 01 Apr '15

01 Apr '15

Dear All, I feel duty-bound to forward to you this morning's Imperial College policy change. David ---------- Forwarded message ---------- From: Director of Mathematics Undergraduate Studies <ma.dug(a)imperial.ac.uk> Date: 1 April 2015 at 08:52 Subject: New College regulations on Lectures start today To: Maths - All Research Associates <ma-all-ras-dl(a)imperial.ac.uk>, Maths - All Academic Staff <ma-all-academic-staff-dl(a)imperial.ac.uk> Dear All, In an attempt to combat plagiarism and inadequate referencing in student projects, the College has decreed that academic staff should lead by example. It is now a strict College regulation that “whenever a lecturer mentions a source by name, an appropriate reference must be supplied.” This sounds reasonable, but I am afraid it will have some unfortunate consequences for us all. >From the start of this month, whenever in lectures we use the name of a mathematician (or other scientist) whether living or dead, we must also provide a full reference. So for example “Poisson’s equation” must henceforth be accompanied by a written reference such as: S.D. Poisson d’Avril, "Remarques sur une équation qui se présente dans la théorie des attractions des sphéroïdes" Nouveau Bull. Soc. Philomathique de Paris, 3 (1813) 388–392. Notes and Clarifications: (1) When citing a dual source, BOTH authors must be credited. So for example Cayley-Hamilton, Euler-Lagrange, Bolzano-Weirstrass, Bose-Einstein each require two references. (2) If a topic is sufficiently standard that the name does not require a capital letter, then no reference need be supplied. Thus “Cartesian coordinates” requires a reference to René Descartes, but “cartesian coordinates” does not. (3) Adjectives, such as Bayesian or Jacobian, will require referencing to the appropriate author. (4) The Head of Dept has been asked to report any failure to comply with these regulations to the pro-rector for Quality Assurance in the Communication of Knowledge (QUACK). Usually, I manage to insulate the department from foolishness of this sort, but alas, not today. If you feel you wish to express concern about these changes, the heads of department or faculty, r.craster(a)ic.ac.uk or fonsdean(a)ic.ac.uk always welcome any constructive criticism. All the best, Jonathan, April 1st 2015 ------------------------------------------------------------- Jonathan Mestel, Professor of Applied Mathematics Director of Undergraduate Studies Mathematics Dept, Imperial College London Tel: 0207 594 8513 Room: Huxley 630 ma.dug(a)ic.ac.uk -- Dr David Ham Departments of Mathematics and Computing Imperial College London http://www.imperial.ac.uk/people/david.ham

1 0

More detailled breakdown of PETSc timings / higher order geometric MG
by Eike Mueller 30 Mar '15

30 Mar '15

Hi Lawrence (cc firedrake), having talked to Rob yesterday, I’m also looking at the performance of the current (non-hybridised) solver at higher order again. As I said, the main bottleneck that makes the geometric multigrid more expensive is the high cost of the velocity mass matrix solve, which I have to do in the Schur-complement forward- and backward substitution (i.e. applying the triangular matrices in the full Schur-complement), and also in the pressure solve (since I don’t use the diagonal-only form, i.e. 'pc_fieldsplit_schur_fact_type': 'FULL'). However, the PETSc solver has to invert the velocity mass matrix as well, so it should be hit by the same costs. Do you know how I can extract the time for this to make a proper comparison? If I run with PETSC_OPTION=-log_summary then I get a breakdown of the PETSc times, I can only get PCApply. I guess what I’m saying is that I'm now unsure what PCApply actually measures. If the PETSc solver does 11 GMRES iterations, it claims that PCApply was called 23 times, so my conjucture is that this measures 11 pressure solves and 11 mass matrix solves, but probably not the time spent in the forward/backward substitution (as I said, I do run with the 'pc_fieldsplit_schur_fact_type': ‘FULL’ option). Can I break those times down further, so that I get, for example, the time spent in the two velocity mass matrix solves in the forward/backward substitution and the time in solving the Schur-complement pressure system M_p + \omega^2*D^T*diag(M_u)*D? Data I have currently: In the matrix-free solver, one velocity mass matrix inverse costs 2.27s, and I need two per iteration just for the forward/backward substitution. On the other hand, one GMRES iteration of the PETSc solver (which includes everything: applying the mixed operator, solving the pressure system, inverting the velocity mass matrices) takes 3.87s, so something is not right there. If I can get a better like-for-like comparison of the times in the PETSc and matrix-free solver it should be possible to identify the bottlenecks. Thanks, Eike

2 1

Extracting components of FieldSplit preconditioner
by Eike Mueller 20 Mar '15

20 Mar '15

Dear firedrakers, I’m trying to extract the components of the field split preconditioner to time them individually, but it fails. I suspect that I’mnot setting up some things, but it’s not obvious what to do. For example, if I do ksp = up_solver.snes.getKSP() ksp.setUp() ksp_hdiv, ksp_schur = ksp.getPC().getFieldSplitSubKSP() # HDiv space ksp_hdiv.setUp() op_hdiv, op_pc_hdiv = ksp_hdiv.getOperators() pc_hdiv = ksp_hdiv.getPC() print pc_hdiv.getType() ndof = op_hdiv.getSizes()[0][0] x = PETSc.Vec() x.create() x.setSizes((ndof, None)) x.setFromOptions() x.setArray(np.random.rand(ndof)) y = x.duplicate() x.setArray(np.zeros(ndof)) pc_hdiv.apply(x,y) with timed_region('pc_hdiv'): pc_hdiv.apply(x,y) I get: bjacobi Traceback (most recent call last): File "driver.py", line 557, in <module> main(parameter_filename) File "driver.py", line 499, in main pc_hdiv.apply(x,y) File "PC.pyx", line 187, in petsc4py.PETSc.PC.apply (src/petsc4py.PETSc.c:132142) petsc4py.PETSc.Error: error code 71 [0] PCApply() line 449 in /Users/eikemueller/PostDocBath/EllipticSolvers/petsc/src/ksp/pc/interface/precon.c [0] PCApply_BJacobi_Singleblock() line 670 in /Users/eikemueller/PostDocBath/EllipticSolvers/petsc/src/ksp/pc/impls/bjacobi/bjacobi.c [0] KSPSolve() line 542 in /Users/eikemueller/PostDocBath/EllipticSolvers/petsc/src/ksp/ksp/interface/itfunc.c [0] KSPSetUp() line 330 in /Users/eikemueller/PostDocBath/EllipticSolvers/petsc/src/ksp/ksp/interface/itfunc.c [0] PCSetUp() line 918 in /Users/eikemueller/PostDocBath/EllipticSolvers/petsc/src/ksp/pc/interface/precon.c [0] PCSetUp_ILU() line 232 in /Users/eikemueller/PostDocBath/EllipticSolvers/petsc/src/ksp/pc/impls/factor/ilu/ilu.c [0] MatLUFactorNumeric() line 2945 in /Users/eikemueller/PostDocBath/EllipticSolvers/petsc/src/mat/interface/matrix.c [0] MatLUFactorNumeric_SeqAIJ() line 566 in /Users/eikemueller/PostDocBath/EllipticSolvers/petsc/src/mat/impls/aij/seq/aijfact.c [0] MatPivotCheck() line 664 in /Users/eikemueller/PostDocBath/EllipticSolvers/petsc/include/petsc-private/matimpl.h [0] MatPivotCheck_none() line 645 in /Users/eikemueller/PostDocBath/EllipticSolvers/petsc/include/petsc-private/matimpl.h [0] Zero pivot in LU factorization: http://www.mcs.anl.gov/petsc/documentation/faq.html#ZeroPivot [0] Zero pivot row 0 value 0 tolerance 2.22045e-14 so it looks to me like the PC is not set up correctly. I use 'fieldsplit_0_ksp_type': 'preonly', 'fieldsplit_0_pc_type': 'bjacobi', 'fieldsplit_0_sub_pc_type': 'ilu’, So I suspect the ILU has not been set up correctly Thanks, Eike The solver parameters are: sparams={'pc_type': 'fieldsplit', 'pc_fieldsplit_type': 'schur', 'ksp_type': 'gmres', 'ksp_max_it': 100, 'ksp_rtol':self._tolerance, 'pc_fieldsplit_schur_fact_type': 'FULL', 'pc_fieldsplit_schur_precondition': 'selfp', 'fieldsplit_0_ksp_type': 'preonly', 'fieldsplit_0_pc_type': 'bjacobi', 'fieldsplit_0_sub_pc_type': 'ilu', 'fieldsplit_1_ksp_type': 'preonly', 'fieldsplit_1_pc_type': 'gamg', 'fieldsplit_1_mg_levels_ksp_type': 'chebyshev', 'fieldsplit_1_mg_levels_ksp_chebyshev_estimate_eigenvalues': True, 'fieldsplit_1_mg_levels_ksp_chebyshev_estimate_eigenvalues_random': True, 'fieldsplit_1_mg_levels_ksp_max_it': 1, 'fieldsplit_1_mg_levels_pc_type': 'bjacobi', 'fieldsplit_1_mg_levels_sub_pc_type': 'ilu', 'ksp_monitor': False}

1 0

More detailled breakdown of PETSc timings / higher order geometric MG
by Eike Mueller 19 Mar '15

19 Mar '15

Hi Lawrence (cc firedrake), (apologies, accidentially sent from my unregistered gmail-account first). having talked to Rob yesterday, I’m also looking at the performance of the current (non-hybridised) solver at higher order again. As I said, the main bottleneck that makes the geometric multigrid more expensive is the high cost of the velocity mass matrix solve, which I have to do in the Schur-complement forward- and backward substitution (i.e. applying the triangular matrices in the full Schur-complement), and also in the pressure solve (since I don’t use the diagonal-only form, i.e. 'pc_fieldsplit_schur_fact_type': 'FULL'). However, the PETSc solver has to invert the velocity mass matrix as well, so it should be hit by the same costs. Do you know how I can extract the time for this to make a proper comparison? If I run with PETSC_OPTION=-log_summary then I get a breakdown of the PETSc times, I can only get PCApply. I guess what I’m saying is that I'm now unsure what PCApply actually measures. If the PETSc solver does 11 GMRES iterations, it claims that PCApply was called 23 times, so my conjucture is that this measures 11 pressure solves and 11 mass matrix solves, but probably not the time spent in the forward/backward substitution (as I said, I do run with the 'pc_fieldsplit_schur_fact_type': ‘FULL’ option). Can I break those times down further, so that I get, for example, the time spent in the two velocity mass matrix solves in the forward/backward substitution and the time in solving the Schur-complement pressure system M_p + \omega^2*D^T*diag(M_u)*D? Data I have currently: In the matrix-free solver, one velocity mass matrix inverse costs 2.27s, and I need two per iteration just for the forward/backward substitution. On the other hand, one GMRES iteration of the PETSc solver (which includes everything: applying the mixed operator, solving the pressure system, inverting the velocity mass matrices) takes 3.87s, so something is not right there. If I can get a better like-for-like comparison of the times in the PETSc and matrix-free solver it should be possible to identify the bottlenecks. Thanks, Eike -- Dr Eike Hermann Mueller Lecturer in Scientific Computing Department of Mathematical Sciences University of Bath Bath BA2 7AY, United Kingdom +44 1225 38 5557 e.mueller(a)bath.ac.uk http://people.bath.ac.uk/em459/

2 5

hybridisation and tensor-product multigrid
by Eike Mueller 18 Mar '15

18 Mar '15

Dear firedrakers, I have two questions regarding the extension of a hybridised solver to a tensor-product approach: (1) In firedrake, is there already a generic way of multiplying locally assembled matrices? I need this for the hybridised solver, so for example I want to (locally) assemble the velocity mass matrix M_u and divergence operator D and then multiply them to get, for example: D^T M_u^{-1} D I can create a hack by assembling them into vector-valued DG0 fields and then writing the necessary operations to multiply them and abstract that into a class (as I did for the column-assembled matrices), but I wanted to check if this is supported generically in firdrake (i.e. if there is support for working with a locally assembled matrix representation). If I can do that, then I can see how I can build all operator that are needed in the hybridised equation and for mapping between the Lagrange multipliers and pressure/velocity. For the columnwise smoother, I then need to extract bits of those locally assembled matrices and assemble them columnwise as for the DG0 case. (2) The other ingredient we need for the Gopalakrishnan and Tan approach is a tensor-product solver in the P1 space. So can I already prolongate/restrict in the horizontal-direction only in this space? I recall that Lawrence wrote a P1 multigrid, but I presume this is for a isotropic grid which is refined in all coordinate directions. Again I can probably do it 'by hand' by just L2 projecting between the spaces, but this will not be the most efficient way. Getting the columnwise smoother should work as for the DG0 case: I need to assemble the matrix locally and then pick out the vertical couplings and build them into a columnwise matrix, which I store as a vector-valued P1 space on the horizontal host-grid. Thanks a lot, Eike -- Dr Eike Hermann Mueller Lecturer in Scientific Computing Department of Mathematical Sciences University of Bath Bath BA2 7AY, United Kingdom +44 1225 38 6241 e.mueller(a)bath.ac.uk http://people.bath.ac.uk/em459/

5 19

Re: [firedrake] hybridisation and tensor-product multigrid
by Andrew McRae 17 Mar '15

17 Mar '15

Miklos: this is a bug, rather than by design. On 17 March 2015 at 15:14, Homolya, Miklós <m.homolya14(a)imperial.ac.uk> wrote: > I'm afraid BrokenElement is not currently functional on extruded (i.e. > OuterProductElements). They should still work on quadrilaterals though. > > > On 17/03/15 14:08, Eike Mueller wrote: > > Hi Miklos, > > thanks, that’s probably what I’m looking for. It works if I just create > a BDFM1 element on a 2d grid, and then say > > U1 = FiniteElement('BDFM',triangle,2) > U1_broken = BrokenElement(U1) > > However, the 3d code below which builds elements on an extruded mesh > does not work. I’ve also tried to first create BrokenElement versions of U1 > and V1, and then combine them, but that doesn’t work either. > > Thanks, > > Eike > > PS: I started writing a class for locally assembling matrices (for this > class it does not matter whether the function spaces are discontinuous or > not, but the multiplying them locally of course only makes sense if the > spaces are discontinuous), see here: > https://github.com/firedrakeproject/firedrake-helmholtzsolver/blob/hybridiz… > It has methods for assembling a UFL form, appling the locally assembled > matrices to a vector, adding and multiplying locally assembled matrices and > calculating the inverse (using dgels from LAPACK). > > from firedrake import * > > host_mesh = UnitIcosahedralSphereMesh(0) > mesh = ExtrudedMesh(host_mesh,layers=4,extrusion_type='radial') > > U1 = FiniteElement('BDFM',triangle,2) > U2 = FiniteElement('DG',triangle,1) > V0 = FiniteElement('CG',interval,2) > V1 = FiniteElement('DG',interval,1) > > W2_elt = HDiv(OuterProductElement(U1,V1))+HDiv(OuterProductElement(U2,V0)) > W2_broken_elt = BrokenElement(W2_elt) > > W = FunctionSpace(mesh,W2_broken_elt) > > WARNING: Creating an EnrichedElement, > if you intended to create a MixedElement use '*' instead of '+'. > Traceback (most recent call last): > File "brokenelement.py", line 14, in <module> > W = FunctionSpace(mesh,W2_broken_elt) > File > "/Users/eikemueller/PostDocBath/EllipticSolvers/PyOP2/pyop2/caching.py", > line 160, in __new__ > obj = make_obj() > File > "/Users/eikemueller/PostDocBath/EllipticSolvers/PyOP2/pyop2/caching.py", > line 141, in make_obj > obj.__init__(*args, **kwargs) > File > "/Users/eikemueller/PostDocBath/EllipticSolvers/firedrake/firedrake/functionspace.py", > line 540, in __init__ > super(FunctionSpace, self).__init__(mesh, element, name, dim=1) > File > "/Users/eikemueller/PostDocBath/EllipticSolvers/firedrake/firedrake/functionspace.py", > line 52, in __init__ > self.flattened_element = self.fiat_element.flattened_element() > AttributeError: Discontinuized instance has no attribute > 'flattened_element' > > -- > > Dr Eike Hermann Mueller > Lecturer in Scientific Computing > > Department of Mathematical Sciences > University of Bath > Bath BA2 7AY, United Kingdom > > +44 1225 38 5557 > e.mueller(a)bath.ac.uk > http://people.bath.ac.uk/em459/ > > On 17 Mar 2015, at 13:34, Miklos Homolya <m.homolya14(a)imperial.ac.uk> > wrote: > > Hi, > > I'm not quite sure, but I think BrokenElement is probably what you need. > BrokenElement keeps all the dofs and transformations and their meaning, > but re-associates all dofs with the cell interior. > > Regards, > Miklos > > > On 17/03/15 13:29, Eike Mueller wrote: > > Hi again, > > Another slight problem is that we don't have trace elements for > quadrilaterals or tensor product elements at the moment. Our approach to > trace spaces is also rather hacked up, we extract the facet basis functions > from an H(div) basis and the tabulator returns DOFs by dotting the local > basis functions by the local normal. > > > we would also need a discontinuous HDiv space, i.e. e.g. discontinuous > versions of RT0 and BDFM1. How can I get those? > > Thanks, > > Eike > > Andrew: presumably you didn't implement them because you anticipated > some fiddliness for tensor-products? > > cheers > --cjc > > On 16 March 2015 at 08:49, Eike Mueller <E.Mueller(a)bath.ac.uk> wrote: > >> Dear firedrakers, >> >> I have two questions regarding the extension of a hybridised solver to a >> tensor-product approach: >> >> (1) In firedrake, is there already a generic way of multiplying locally >> assembled matrices? I need this for the hybridised solver, so for example I >> want to (locally) assemble the velocity mass matrix M_u and divergence >> operator D and then multiply them to get, for example: >> >> D^T M_u^{-1} D >> >> I can create a hack by assembling them into vector-valued DG0 fields and >> then writing the necessary operations to multiply them and abstract that >> into a class (as I did for the column-assembled matrices), but I wanted to >> check if this is supported generically in firdrake (i.e. if there is >> support for working with a locally assembled matrix representation). If I >> can do that, then I can see how I can build all operator that are needed in >> the hybridised equation and for mapping between the Lagrange multipliers >> and pressure/velocity. For the columnwise smoother, I then need to extract >> bits of those locally assembled matrices and assemble them columnwise as >> for the DG0 case. >> >> (2) The other ingredient we need for the Gopalakrishnan and Tan approach >> is a tensor-product solver in the P1 space. So can I already >> prolongate/restrict in the horizontal-direction only in this space? I >> recall that Lawrence wrote a P1 multigrid, but I presume this is for a >> isotropic grid which is refined in all coordinate directions. Again I can >> probably do it 'by hand' by just L2 projecting between the spaces, but this >> will not be the most efficient way. Getting the columnwise smoother should >> work as for the DG0 case: I need to assemble the matrix locally and then >> pick out the vertical couplings and build them into a columnwise matrix, >> which I store as a vector-valued P1 space on the horizontal host-grid. >> >> Thanks a lot, >> >> Eike >> >> -- >> Dr Eike Hermann Mueller >> Lecturer in Scientific Computing >> >> Department of Mathematical Sciences >> University of Bath >> Bath BA2 7AY, United Kingdom >> >> +44 1225 38 6241 >> e.mueller(a)bath.ac.uk >> http://people.bath.ac.uk/em459/ >> >> _______________________________________________ >> firedrake mailing list >> firedrake(a)imperial.ac.uk >> https://mailman.ic.ac.uk/mailman/listinfo/firedrake >> > > _______________________________________________ > firedrake mailing list > firedrake(a)imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/firedrake > > > > > _______________________________________________ > firedrake mailing listfiredrake@imperial.ac.ukhttps://mailman.ic.ac.uk/mailman/listinfo/firedrake > > > _______________________________________________ > firedrake mailing list > firedrake(a)imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/firedrake > > > > > _______________________________________________ > firedrake mailing listfiredrake@imperial.ac.ukhttps://mailman.ic.ac.uk/mailman/listinfo/firedrake > > >

1 0

Re: [firedrake] hybridisation and tensor-product multigrid
by Andrew McRae 16 Mar '15

16 Mar '15

Officially I'd prefer you to use FacetElement and write dot(u, n). Trace elements were a quick hack. Their FIAT implementation essentially does this, though on the reference cell, inside the tabulate() function. If anyone wants to spend half-a-day extending FIAT's trace.py to work with arbitrary H(div) elements then be my guest. On 16 March 2015 at 14:25, Cotter, Colin J <colin.cotter(a)imperial.ac.uk> wrote: > Hi Eike, > If you take a look at the test_hybridisation_inverse branch, in > tests/regression/test_hybridisation_schur, you'll see a hacked up attempt > at doing this for simplices. It's a bit fiddly because you need to assemble > the form multiple times, once as a mixed system and once as a single block, > so I'm thinking of making a tool to automate some of this by doing > automated substitutions in UFL. Lawrence and I said we might try to sketch > out how to do this. > > Another slight problem is that we don't have trace elements for > quadrilaterals or tensor product elements at the moment. Our approach to > trace spaces is also rather hacked up, we extract the facet basis functions > from an H(div) basis and the tabulator returns DOFs by dotting the local > basis functions by the local normal. > > Andrew: presumably you didn't implement them because you anticipated some > fiddliness for tensor-products? > > cheers > --cjc > > On 16 March 2015 at 08:49, Eike Mueller <E.Mueller(a)bath.ac.uk> wrote: > >> Dear firedrakers, >> >> I have two questions regarding the extension of a hybridised solver to a >> tensor-product approach: >> >> (1) In firedrake, is there already a generic way of multiplying locally >> assembled matrices? I need this for the hybridised solver, so for example I >> want to (locally) assemble the velocity mass matrix M_u and divergence >> operator D and then multiply them to get, for example: >> >> D^T M_u^{-1} D >> >> I can create a hack by assembling them into vector-valued DG0 fields and >> then writing the necessary operations to multiply them and abstract that >> into a class (as I did for the column-assembled matrices), but I wanted to >> check if this is supported generically in firdrake (i.e. if there is >> support for working with a locally assembled matrix representation). If I >> can do that, then I can see how I can build all operator that are needed in >> the hybridised equation and for mapping between the Lagrange multipliers >> and pressure/velocity. For the columnwise smoother, I then need to extract >> bits of those locally assembled matrices and assemble them columnwise as >> for the DG0 case. >> >> (2) The other ingredient we need for the Gopalakrishnan and Tan approach >> is a tensor-product solver in the P1 space. So can I already >> prolongate/restrict in the horizontal-direction only in this space? I >> recall that Lawrence wrote a P1 multigrid, but I presume this is for a >> isotropic grid which is refined in all coordinate directions. Again I can >> probably do it 'by hand' by just L2 projecting between the spaces, but this >> will not be the most efficient way. Getting the columnwise smoother should >> work as for the DG0 case: I need to assemble the matrix locally and then >> pick out the vertical couplings and build them into a columnwise matrix, >> which I store as a vector-valued P1 space on the horizontal host-grid. >> >> Thanks a lot, >> >> Eike >> >> -- >> Dr Eike Hermann Mueller >> Lecturer in Scientific Computing >> >> Department of Mathematical Sciences >> University of Bath >> Bath BA2 7AY, United Kingdom >> >> +44 1225 38 6241 >> e.mueller(a)bath.ac.uk >> http://people.bath.ac.uk/em459/ >> >> _______________________________________________ >> firedrake mailing list >> firedrake(a)imperial.ac.uk >> https://mailman.ic.ac.uk/mailman/listinfo/firedrake >> > >

4 3

Re: [firedrake] hybridisation and tensor-product multigrid
by David Ham 16 Mar '15

16 Mar '15

Hi Eike, Lawrence will have to answer 2. As to number 1, we can't do it yet, but I suspect it's not actually too hard to do if we can work out the syntax for doing it. In implementation it's kind of similar in spirit to the inverse assembly that we just implemented. Cheers, David On 16 March 2015 at 08:49, Eike Mueller <E.Mueller(a)bath.ac.uk> wrote: > Dear firedrakers, > > I have two questions regarding the extension of a hybridised solver to a > tensor-product approach: > > (1) In firedrake, is there already a generic way of multiplying locally > assembled matrices? I need this for the hybridised solver, so for > example I want to (locally) assemble the velocity mass matrix M_u and > divergence operator D and then multiply them to get, for example: > > D^T M_u^{-1} D > > I can create a hack by assembling them into vector-valued DG0 fields and > then writing the necessary operations to multiply them and abstract that > into a class (as I did for the column-assembled matrices), but I wanted > to check if this is supported generically in firdrake (i.e. if there is > support for working with a locally assembled matrix representation). If > I can do that, then I can see how I can build all operator that are > needed in the hybridised equation and for mapping between the Lagrange > multipliers and pressure/velocity. For the columnwise smoother, I then > need to extract bits of those locally assembled matrices and assemble > them columnwise as for the DG0 case. > > (2) The other ingredient we need for the Gopalakrishnan and Tan approach > is a tensor-product solver in the P1 space. So can I already > prolongate/restrict in the horizontal-direction only in this space? I > recall that Lawrence wrote a P1 multigrid, but I presume this is for a > isotropic grid which is refined in all coordinate directions. Again I > can probably do it 'by hand' by just L2 projecting between the spaces, > but this will not be the most efficient way. Getting the columnwise > smoother should work as for the DG0 case: I need to assemble the matrix > locally and then pick out the vertical couplings and build them into a > columnwise matrix, which I store as a vector-valued P1 space on the > horizontal host-grid. > > Thanks a lot, > > Eike > > -- > Dr Eike Hermann Mueller > Lecturer in Scientific Computing > > Department of Mathematical Sciences > University of Bath > Bath BA2 7AY, United Kingdom > > +44 1225 38 6241 > e.mueller(a)bath.ac.uk > http://people.bath.ac.uk/em459/ > > _______________________________________________ > firedrake mailing list > firedrake(a)imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/firedrake > -- Dr David Ham Departments of Mathematics and Computing Imperial College London http://www.imperial.ac.uk/people/david.ham

1 0

Perturbed extruded meshes
by Eike Mueller 07 Mar '15

07 Mar '15

Dear firdrakers, how can I perturb an extruded mesh? I want to add 'mountains' (i.e. bumps) to my spherical icosahedral mesh, so I want to change the radius according to something like r = r(theta) = R_earth+H*exp(-0.5*theta^2/D^2) Can I do this by moving around the underlying 2d host grid and then extruding that? How can I perturb the 2d grid? Thanks a lot, Eike

5 9