- firedrake - imperial.ac.uk

problems with upgrading PETSc and firedrake
by Eike Mueller 17 Oct '15

17 Oct '15

Dear firedrake, I just updated petsc and petsc4py (both from mapdes, using the ‘firedrake’ branch), but now whenever I try to create a mesh from firedrake import * mesh = UnitIcosahedralSphereMesh(refinement_level=2) I just get a PETSc error (see below). I also upgraded both PyOP2 and firedrake (both on ‘master’), and ran firedrake-clean, but that doesn’t help. Thanks, Eike eikemueller@Eikes-MBP $ python test.py [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range [0]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger [0]PETSC ERROR: or see http://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind [0]PETSC ERROR: or try http://valgrind.org on GNU/linux and Apple Mac OS X to find memory corruption errors [0]PETSC ERROR: configure using --with-debugging=yes, recompile, link, and run [0]PETSC ERROR: to get more information on the crash. -------------------------------------------------------------------------- MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD with errorcode 59. NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes. You may or may not see output from other processes, depending on exactly when Open MPI kills them. --------------------------------------------------------------------------

1 0

Dirichlet BC on extruded mesh with discontinuous function space
by Buesing, Henrik 16 Oct '15

16 Oct '15

Dear Firedrakers, I'm constructing a DG space on an extruded mesh. meshbase = RectangleMesh(Nx, Ny, Lx, Ly, quadrilateral=True) mesh = ExtrudedMesh(meshbase, Nz, Delta_z) horiz_elt = FiniteElement("DG", quadrilateral, 0) vert_elt = FiniteElement("DG", interval, 0) elt = OuterProductElement(horiz_elt, vert_elt) DG = FunctionSpace(mesh, elt) W=DG*DG Now I would like to impose Dirchlet BC on one of the boundaries. I tried bc0 = DirichletBC(W.sub(0), Expression("1.0e7"), 2,method="geometric") and get a ValueError: Geometric boundary conditions are not yet supported on extruded meshes Using the standard topological way, seems to have no effect at all. Is there a way around this? I would be fine with fixing the value on the most outer cell layer, if that is possible... Henrik -- Dipl.-Math. Henrik Büsing Institute for Applied Geophysics and Geothermal Energy E.ON Energy Research Center RWTH Aachen University ------------------------------------------------------ Mathieustr. 10 | Tel +49 (0)241 80 49907 52074 Aachen, Germany | Fax +49 (0)241 80 49889 ------------------------------------------------------ http://www.eonerc.rwth-aachen.de/GGE hbuesing(a)eonerc.rwth-aachen.de ------------------------------------------------------

3 4

Re: [firedrake] Preconditioner for Least-squares FEM
by Andrew McRae 15 Oct '15

15 Oct '15

As usual, the Firedrake person in the best position to answer your question is Lawrence, but he's currently on holiday. I won't try to answer your question, but in an old email <http://mailman.ic.ac.uk/pipermail/firedrake/2015-July/000953.html>, Lawrence suggested you try using multigrid on the blocks; e.g. 'fieldsplit_0_pc_type': 'gamg', 'fieldsplit_1_pc_type': 'gamg', My linear solver knowledge is pretty dire, so I'll stop talking here :) Andrew On 15 October 2015 at 13:58, Justin Chang <jychang48(a)gmail.com> wrote: > I did ask them, but it went unanswered for the last 1.5 months... > > Let me clarify my question a bit though, I tried using -ksp_type cg > -pc_type hypre -pc_hypre_type boomeramg, but it is not supported for > matnest. I added nest=False but it seems to break my solver somehow. > > The only thing that works for me is -ksp_type cg -pc_type bjacobi plus > MixedVectorSpaceBasis(W, ...) but the number of solver iterations increases > with problem size... > > Thanks, > Justin > > On Thu, Oct 15, 2015 at 6:50 AM, Andrew McRae <A.T.T.McRae(a)bath.ac.uk> > wrote: > >> I think the PETSc mailing list is a much better place to ask questions >> like this? >> >> On 15 October 2015 at 13:47, Justin Chang <jychang48(a)gmail.com> wrote: >> >>> Hi all, >>> >>> I am attempting to solve Darcy's equation: >>> >>> u + grad[p] = 0 >>> div[u] = f >>> >>> The weak form under the least-squares finite element method (LSFEM) >>> looks like this: >>> >>> (u + grad[p]; v + grad[q]) + div[u]*div[v] = (f; div[v]) >>> >>> For H(div) elements like RT0, these options worked nicely: >>> >>> -ksp_type gmres >>> -pc_type fieldsplit >>> -pc_fieldsplit_type schur >>> -pc_fieldsplit_schur_precondition selfp >>> -fieldsplit_0_ksp_type preonly >>> -fieldsplit_0_pc_type bjacobi >>> -fieldsplit_0_sub_pc_type ilu >>> -fieldsplir_1_ksp_type preonly >>> -fieldsplit_1_pc_type hypre >>> >>> but for the above LSFEM, it does not work (get a DIVERGED_MAX_IT error). >>> I heard multigrid methods are good for these types of problems, so how do I >>> tweak the above parameters? >>> >>> Thanks, >>> Justin >>> >> >> >> _______________________________________________ >> firedrake mailing list >> firedrake(a)imperial.ac.uk >> https://mailman.ic.ac.uk/mailman/listinfo/firedrake >> >> >

2 1

Re: [firedrake] Preconditioner for Least-squares FEM
by Andrew McRae 15 Oct '15

15 Oct '15

I think the PETSc mailing list is a much better place to ask questions like this? On 15 October 2015 at 13:47, Justin Chang <jychang48(a)gmail.com> wrote: > Hi all, > > I am attempting to solve Darcy's equation: > > u + grad[p] = 0 > div[u] = f > > The weak form under the least-squares finite element method (LSFEM) > looks like this: > > (u + grad[p]; v + grad[q]) + div[u]*div[v] = (f; div[v]) > > For H(div) elements like RT0, these options worked nicely: > > -ksp_type gmres > -pc_type fieldsplit > -pc_fieldsplit_type schur > -pc_fieldsplit_schur_precondition selfp > -fieldsplit_0_ksp_type preonly > -fieldsplit_0_pc_type bjacobi > -fieldsplit_0_sub_pc_type ilu > -fieldsplir_1_ksp_type preonly > -fieldsplit_1_pc_type hypre > > but for the above LSFEM, it does not work (get a DIVERGED_MAX_IT error). I > heard multigrid methods are good for these types of problems, so how do I > tweak the above parameters? > > Thanks, > Justin >

2 1

Preconditioner for Least-squares FEM
by Justin Chang 15 Oct '15

15 Oct '15

Hi all, I am attempting to solve Darcy's equation: u + grad[p] = 0 div[u] = f The weak form under the least-squares finite element method (LSFEM) looks like this: (u + grad[p]; v + grad[q]) + div[u]*div[v] = (f; div[v]) For H(div) elements like RT0, these options worked nicely: -ksp_type gmres -pc_type fieldsplit -pc_fieldsplit_type schur -pc_fieldsplit_schur_precondition selfp -fieldsplit_0_ksp_type preonly -fieldsplit_0_pc_type bjacobi -fieldsplit_0_sub_pc_type ilu -fieldsplir_1_ksp_type preonly -fieldsplit_1_pc_type hypre but for the above LSFEM, it does not work (get a DIVERGED_MAX_IT error). I heard multigrid methods are good for these types of problems, so how do I tweak the above parameters? Thanks, Justin

1 0

Re: [firedrake] Unwise rebase
by Andrew McRae 14 Oct '15

14 Oct '15

Hi Eike, I'm afraid I don't understand, from that description, what exactly has happened. I guess the main question is whether you had a merge conflict along the way; if not then it should be trivial to fix up. Let's sort this out tomorrow morning if that's convenient? Andrew On 13 October 2015 at 19:36, Eike Mueller <E.Mueller(a)bath.ac.uk> wrote: > Dear firedrake, > > I just realised that I made a stupid mistake and rebased the PyOP2 > performance-logging branch (which is racking a remote branch) on master. > > After syncing with the remote I end up with two sets of commits in my > branch. Is there a safe way of fixing this or do I just have to live with > the confusing history now? > > Sorry! > > Eike > > > > _______________________________________________ > firedrake mailing list > firedrake(a)imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/firedrake >

3 2

Unwise rebase
by Eike Mueller 13 Oct '15

13 Oct '15

Dear firedrake, I just realised that I made a stupid mistake and rebased the PyOP2 performance-logging branch (which is racking a remote branch) on master. After syncing with the remote I end up with two sets of commits in my branch. Is there a safe way of fixing this or do I just have to live with the confusing history now? Sorry! Eike

1 0

Re: [firedrake] PyOP2 pull request #465
by David Ham 13 Oct '15

13 Oct '15

Aaargh! Damn. Can you report this as a bug and I'll try to find time to get onto it. David On Tue, 13 Oct 2015 at 15:35 Eike Mueller <E.Mueller(a)bath.ac.uk> wrote: > Dear all, > > actually, on my mac, I need to add the flag ‘-Wa,-q’ to get the code to > compile, otherwise I get errors of this type: > > […] > /var/folders/yy/9wfgymp14_1b9zt2x0ycs64m0000gn/T//ccIqsgIb.s:9:no such > instruction: `vxorpd %xmm5, %xmm5,%xmm5' > /var/folders/yy/9wfgymp14_1b9zt2x0ycs64m0000gn/T//ccIqsgIb.s:12:no such > instruction: `vmovsd LC1(%rip), %xmm2’ > […] > > Also, I need to be able to specify additional libraries and their paths (I > need LAPACK and BLAS). What I did in the past is this: > > > https://github.com/OP2/PyOP2/commit/865b66ea4c399a9de0949388103a964cb89b2b91 > > (that’s in the columnwise kernel branch, and I think those changes never > made it into master). > > Looking at the kernel constructor in base.py, I think at the moment I can > only pass include directories and headers, but I can’t see how I can pass > linker options. > > def __init__(self, code, name, opts={}, include_dirs=[], headers=[], > user_code="", cpp=False): > > I can go ahead and add functionality for specifying library paths in a > branch and create a pull request, but maybe you already solved this > differently and I just can’t figure out how to pass in the library paths > correctly? > > Thanks, > > Eike > > > On 13 Oct 2015, at 09:38, Eike Mueller <E.Mueller(a)bath.ac.uk> wrote: > > Ok, that's great, thanks a lot! I will give it a go. > > Eike > > PS: I will be in London next week, so I arranged with Lawrence to meet on > Wednesday (21 Oct). I'll probably come down the day before but will also > try arrange some placement visits for the Tuesday afternoon. > > ------------------------------ > *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:* 13 October 2015 09:31 > *To:* firedrake > *Subject:* Re: [firedrake] PyOP2 pull request #465 > > > Hi Eike, > > Lawrence is on holiday so I'm taking a rash executive decision to merge > that pull request. If it breaks Firedrake (unlikely) I'll have to pull it > again. > > Regards, > > David > > On Mon, 12 Oct 2015 at 17:54 Eike Mueller <E.Mueller(a)bath.ac.uk> wrote: > >> Dear firedrake, >> >> what's the status of PyOP2 pull request #465 ( >> https://github.com/OP2/PyOP2/pull/465) >> <https://github.com/OP2/PyOP2/pull/465>? Is this about to be merged? >> >> I've got some changes in my code that depend on it (both in the geometric >> multigrid code and the performance logging branch), so would be great to >> have support for C++ kernels in the master. >> >> Thanks, >> >> Eike >> >> >> _______________________________________________ > firedrake mailing list > firedrake(a)imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/firedrake > > >

2 1

Re: [firedrake] PyOP2 pull request #465
by David Ham 13 Oct '15

13 Oct '15

Hi Eike, Lawrence is on holiday so I'm taking a rash executive decision to merge that pull request. If it breaks Firedrake (unlikely) I'll have to pull it again. Regards, David On Mon, 12 Oct 2015 at 17:54 Eike Mueller <E.Mueller(a)bath.ac.uk> wrote: > Dear firedrake, > > > what's the status of PyOP2 pull request #465 ( > https://github.com/OP2/PyOP2/pull/465) > <https://github.com/OP2/PyOP2/pull/465>? Is this about to be merged? > > > I've got some changes in my code that depend on it (both in the geometric > multigrid code and the performance logging branch), so would be great to > have support for C++ kernels in the master. > > > Thanks, > > > Eike > > > >

2 2

PyOP2 pull request #465
by Eike Mueller 12 Oct '15

12 Oct '15

Dear firedrake, what's the status of PyOP2 pull request #465 (https://github.com/OP2/PyOP2/pull/465)<https://github.com/OP2/PyOP2/pull/465>? Is this about to be merged? I've got some changes in my code that depend on it (both in the geometric multigrid code and the performance logging branch), so would be great to have support for C++ kernels in the master. Thanks, Eike

1 0