- firedrake - imperial.ac.uk

Firedrake '17 submissions are now open.
by David Ham 16 Dec '16

16 Dec '16

Dear Firedrakers, The first Firedrake user and developer workshop will be held at Imperial College London on 27 and 28 March 2017. The workshop will be an opportunity for the Firedrake community to communicate new applications and developments in Firedrake, a chance for face-to-face time with the developer team, and will feature a tutorial for new users. Submissions of oral and poster contributions are now open. More information on this and the workshop in general are available at http://www.firedrakeproject.org/firedrake_17.html Regards, David -- Dr David Ham Department of Mathematics Imperial College London

1 0

Re: [firedrake] Firedrake
by Lawrence Mitchell 12 Dec '16

12 Dec '16

Dear Patrick, Thomas, [note: writing email directly to me to try and solve problems with Firedrake is not the way to get a fast response. Please send issues to the Firedrake mailing list (cc'd now)] > On 11 Dec 2016, at 11:20, Patrick Farrell <patrick.farrell(a)maths.ox.ac.uk> wrote: > > Dear Lawrence, > > A colleague of mine, Thomas Surowiec, is trying to install firedrake on OSX 10.10.3. > Unfortunately the firedrake-install script isn't working out of the box. > > It appears that OSX has decided to put mpif90 in /usr/local/Cellar/open-mpi/1.10.2/bin/mpif90, > but the PETSc compilation is looking for it in /usr/local/bin/. Any idea why, or what we can > do? What does: $ env $ which mpif90 $ which gfortran $ which python $ cat > foo.f90 << \EOF program main use mpi end $ mpif90 foo.f90 Give? It looks like the MPI compiler is somehow not working? > > > -------- Forwarded Message -------- > Subject: Re: Firedrake > Date: Sun, 11 Dec 2016 12:06:26 +0100 > From: Thomas Surowiec <thomas.surowiec(a)gmail.com> > To: Patrick Farrell <patrick.farrell(a)maths.ox.ac.uk> > > Still a mess. It went a few steps further, but there were problems with the security features. In case you're interested the complete output is below. Are there now several half compiled versions and folders associated with fenics and firedrake on my system? Is there anyway to delete all of them and start over? Other than the homebrew dependencies, firedrake-install puts *everything* inside the "firedrake" subdirectory of the working directory that you ran firedrake-install in. You can safely just delete this subtree. > ThomasSsMacBook:~ anounz$ /usr/bin/python firedrake-install All of our testing is done with the homebrew python, rather than the system python. I do not know if this will cause issues, but all of us with Mac systems use the python that homebrew puts in /usr/local/bin. Lawrence

3 2

FInAT has landed!
by Homolya, Miklós 12 Dec '16

12 Dec '16

Dear Firedrakers, An updated form compilation system has just been merged into Firedrake. FInAT, a new component, is a finite element library that is able to express structure in the finite elements themselves; this structure is then exploited by TSFC and COFFEE for optimisation. Most important benefits: - Automatic sum factorisation for Q/DQ elements. - Better code generation for vector/tensor elements and more compact element tables. So if you use CG/DG elements on non-simplex cells (quadrilaterals and extruded), you will likely see significant assembly time improvements, depending on polynomial order (higher gain with higher order). Sum factorisation for H(div)/H(curl) conforming elements (RTCF, RTCE, NCF, NCE) is not supported yet, nor for any elements on simplices. Update instructions: nothing special, just run firedrake-update. Best wishes, Miklós

3 2

Re: [firedrake] Problems with NonlinearVariationalProblem
by Andrew McRae 11 Dec '16

11 Dec '16

Your F uses psi_non, a Function, and psi, a TrialFunction. Probably you meant to replace psi with phi, which was defined as a TestFunction? Best, Andrew On 11 December 2016 at 02:42, Francis Poulin <fpoulin(a)uwaterloo.ca> wrote: > Hello Andrew, > > Thanks for pointing that out. > > I have looked at the Burger equation demo more and think I understand it > better. > > If you go to the following link you will see that there is a revised > version of the code. Now I solve the linear problem first, since that > should be used as an initial guess. Then I want to solve the Nonlinear > Variational Problem. > > https://github.com/francispoulin/firedrakeQG/blob/master/fofonoff_qg.py > > Unfortunately, I haven't figured out how to get the syntax correct. I'm > only using a Function, with the guess an the variable to determine, and a > Test Function. > > Any advice would be greatly appreciated. > > Cheers, 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 <(519)%20888-4567> > > ------------------------------ > *From:* firedrake-bounces(a)imperial.ac.uk [firedrake-bounces(a)imperial.ac.uk] > on behalf of Andrew McRae [A.T.T.McRae(a)bath.ac.uk] > *Sent:* Friday, December 09, 2016 4:49 PM > *To:* Firedrake Project > *Subject:* Re: [firedrake] Problems with NonlinearVariationalProblem > > Hi Francis, > > The residual should be linear in the Test Function, and TrialFunctions > should not appear at all (a Function should be used instead). > > Best, > Andrew > > On 9 Dec 2016 8:58 p.m., "Francis Poulin" <fpoulin(a)uwaterloo.ca> wrote: > >> Hello, >> >> We have been following the documentation and examples to learn how to >> solve nonlinear problems in Firedrake. We want to solve the classical >> Fofonoff problem in a one-layer Quasi-Geostrophic problem. >> >> We have set up a nonlinear variational problem, following the >> Camassa-Holm demo. Unfortunately, whenever we try it we get an error >> saying that our for is not a linear form. Which is true, but since we are >> using NonlinearVariationalProblem, I presume this should be ok. >> >> Traceback (most recent call last): >> File "fofonoff_qg.py", line 41, in <module> >> psi_problem = NonlinearVariationalProblem(L, psi_soln, bcs=bc) >> File "/home/fpoulin/software/firedrake/src/firedrake/firedrake/variational_solver.py", >> line 47, in __init__ >> raise ValueError("Provided residual is not a linear form") >> ValueError: Provided residual is not a linear form >> >> Our code can be found on github. >> >> https://github.com/francispoulin/firedrakeQG/blob/master/fofonoff_qg.py >> >> If anyone has any advice or other examples that do this successfully, we >> would love to know more. >> >> Cheers, 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 <(519)%20888-4567> >> >>

2 1

Re: [firedrake] Problems with NonlinearVariationalProblem
by Andrew McRae 11 Dec '16

11 Dec '16

Hi Francis, The residual should be linear in the Test Function, and TrialFunctions should not appear at all (a Function should be used instead). Best, Andrew On 9 Dec 2016 8:58 p.m., "Francis Poulin" <fpoulin(a)uwaterloo.ca> wrote: > Hello, > > We have been following the documentation and examples to learn how to > solve nonlinear problems in Firedrake. We want to solve the classical > Fofonoff problem in a one-layer Quasi-Geostrophic problem. > > We have set up a nonlinear variational problem, following the Camassa-Holm > demo. Unfortunately, whenever we try it we get an error saying that our > for is not a linear form. Which is true, but since we are using > NonlinearVariationalProblem, I presume this should be ok. > > Traceback (most recent call last): > File "fofonoff_qg.py", line 41, in <module> > psi_problem = NonlinearVariationalProblem(L, psi_soln, bcs=bc) > File "/home/fpoulin/software/firedrake/src/firedrake/ > firedrake/variational_solver.py", line 47, in __init__ > raise ValueError("Provided residual is not a linear form") > ValueError: Provided residual is not a linear form > > Our code can be found on github. > > https://github.com/francispoulin/firedrakeQG/blob/master/fofonoff_qg.py > > If anyone has any advice or other examples that do this successfully, we > would love to know more. > > Cheers, 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 <(519)%20888-4567> > >

2 1

Problems with NonlinearVariationalProblem
by Francis Poulin 09 Dec '16

09 Dec '16

Hello, We have been following the documentation and examples to learn how to solve nonlinear problems in Firedrake. We want to solve the classical Fofonoff problem in a one-layer Quasi-Geostrophic problem. We have set up a nonlinear variational problem, following the Camassa-Holm demo. Unfortunately, whenever we try it we get an error saying that our for is not a linear form. Which is true, but since we are using NonlinearVariationalProblem, I presume this should be ok. Traceback (most recent call last): File "fofonoff_qg.py", line 41, in <module> psi_problem = NonlinearVariationalProblem(L, psi_soln, bcs=bc) File "/home/fpoulin/software/firedrake/src/firedrake/firedrake/variational_solver.py", line 47, in __init__ raise ValueError("Provided residual is not a linear form") ValueError: Provided residual is not a linear form Our code can be found on github. https://github.com/francispoulin/firedrakeQG/blob/master/fofonoff_qg.py If anyone has any advice or other examples that do this successfully, we would love to know more. Cheers, 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

1 0

Re: [firedrake] Mixed system
by David Ham 08 Dec '16

08 Dec '16

Hi Anna, 21d, which is the problematic case, isn't a differential equation. Could you not have symbolically eliminated this equation before this point so it just doesn't occur in the formulation at all? Regards, David On Fri, 2 Dec 2016 at 18:20 Anna Kalogirou <a.kalogirou(a)leeds.ac.uk> wrote: > Hi David, > > The most relevant part is Section 4.2 (page 5). Thank you very much! > > Best, Anna. > > > On 02/12/16 17:46, David Ham wrote: > > > > On Fri, 2 Dec 2016 at 17:36 Anna Kalogirou <a.kalogirou(a)leeds.ac.uk> > wrote: > > Dear David, > > (1) I had a similar problem with heaviside functions some time ago and it > was working. I remember in a discussion with Lawrence he mentioned that it > might just pick up the nonzero values if I don't use preconditioning, which > is not the case here. So how can I overcome this problem now? > > > Relying on the solver to not barf is pretty unreliable in this case. Can > you post a write-up of some sort of the maths of what this code is supposed > to do so I can try to see what the deal is? > > > > (2) So in summary I now only need: > real-function-space branch from firedrake > and > firedrake branch from petsc4py? > I am not currently using the latter, should I..? > > > Yes. The default position (i.e. what happens in firedrake-install if you > don't tell it otherwise) is you have master for everything except petsc and > petsc4py, which are both on branch firedrake. We're now back to that case > for everything except firedrake, which is on real-function-space > > > > Thanks, > > Anna. > > > On 02/12/16 17:01, David Ham wrote: > > Hi Anna, > > I think that possibly does make your system ill-posed. What value is mu_t > supposed to take in the region where lambda_bar is zero? How do the > equations enforce this? It kind of looks like those rows of your system are > simply undefined - which will cause the solver to fail (correctly). > > > In an unrelated point, we have merged the PyOP2 branch and upstream have > merged the petsc4py branch, so you should be able to go back to master for > those two at this stage. You still need the real-function-space branch of > Firedrake itself. > > Regards, > > David > > > > On Fri, 2 Dec 2016 at 16:54 Anna Kalogirou <a.kalogirou(a)leeds.ac.uk> > wrote: > > Hi David, > > The term lambda_bar is zero in the first part of the domain and takes > non-zero values only in a part of the domain, which physically represents > the region where the presence of a ship constrains the free-water surface. > > Analogously, the term mu_bar is zero in that region and non-zero where > there's only water. > > These terms are essentially like heaviside functions. > > Best, > > Anna. > > > On 02/12/16 16:45, David Ham wrote: > > Hi Anna, > > I believe I have found your problem. The test and trial functions for the > 3rd block are v_4 and mu_t respectively. The relevant term is: > amu = v4*(mu_bar*lambda_t + lambda_bar*mu_t)*dx > > i.e. the diagonal block is: > > v4*lambda_bar*mu_t*dx. > > However, if I plot lambda_bar, I find that it is zero over most of the > domain. Most rows of this block are therefore zero with the result that the > solver fails on this block. > > Now it can be that the diagonal blocks are supposed to be zero and that > the problem is still well-posed (as with mixed Poisson, for example). > However that situation needs to be dealt with in the right way in a field > split preconditioner. Before we get there, what is the argument in this > case that this problem is in fact well-posed? > > Regards, > > David > > On Fri, 2 Dec 2016 at 16:20 David Ham <David.Ham(a)imperial.ac.uk> wrote: > > On Fri, 2 Dec 2016 at 16:12 Mitchell, Lawrence < > lawrence.mitchell(a)imperial.ac.uk> wrote: > > > > On 2 Dec 2016, at 16:01, Anna Kalogirou <a.kalogirou(a)leeds.ac.uk> wrote: > > > > Linear firedrake_0_fieldsplit_3_ solve did not converge due to > DIVERGED_DTOL iterations 35 > > > > The option > > > > "fieldsplit_3_pc_factor_shift_type": "nonzero" > > Given that LU with pivoting ought to invert the block unless it is > singular, I think something funky is going on. > > Can you additionally run with: > > "fieldsplit_3_ksp_monitor_true_residual": True > > (In passing, if you're using LU you should probably be setting the > ksp_type of these sub solves to "preonly", so you don't bother iterating). > > > The function space is CG1. I believe that has diagonally dominant mass > matrices so we shouldn't actually need pivotting. > > > > Lawrence > _______________________________________________ > 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 listfiredrake@imperial.ac.ukhttps://mailman.ic.ac.uk/mailman/listinfo/firedrake > > > > > _______________________________________________ > firedrake mailing listfiredrake@imperial.ac.ukhttps://mailman.ic.ac.uk/mailman/listinfo/firedrake > > >

2 1

Re: [firedrake] eigenvalue problems with SLEPc
by David Ham 07 Dec '16

07 Dec '16

Hi Francis, We are always spectacularly happy when people volunteer to write documentation, so yes please! Cheers, David On Thu, 1 Dec 2016 at 15:20 Francis Poulin <fpoulin(a)uwaterloo.ca> wrote: > Hello David, > > I am very sorry that I mis-spoke. Clearly there were many differences and > those differences make all the difference. > > Thank you very much for presenting the two methods, that helps a great > deal on how to set the PETSc options while keeping the basic structure. > This is very, very helpful. > > One last question I hope. Would you be interested in me putting together a > demo for other firedrakers? If yes I should be able to do it within a week > or so. > > Cheers, 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 <(519)%20888-4567> > > > ________________________________________ > 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: Thursday, December 01, 2016 4:54 AM > To: firedrake(a)imperial.ac.uk > Subject: Re: [firedrake] eigenvalue problems with SLEPc > > On 01/12/16 00:27, Francis Poulin wrote: > > Hello David, > > > > Thanks for the idea. In your example you had your a matrix and then m > > matrix. I presume the second is the mass matrix. > > > > In my case I do have a and then m. I suppose that even if I had it > > mixed up, I would get the inverse of the eigenvalue. > > > > In case anyone has any ideas I am including two lines. > > > > The first is my firedrake code which does not work. > > > > > https://github.com/francispoulin/firedrakeQG/blob/master/basin_modes_qg.py > > > > The second is a fenics version of the code which does work. > > > > > https://github.com/francispoulin/firedrakeQG/blob/master/basin_modes_qg_fen… > > > > To my non-expert eyes they seem to be doing the same thing but clearly > > they are not. > > In the firedrake code you do: > > num_eigenvalues = 5 > # Create solver > es = SLEPc.EPS().create(comm=COMM_WORLD) > es.setProblemType(es.ProblemType.GHEP) > es.setWhichEigenpairs(es.Which.SMALLEST_IMAGINARY) > es.setDimensions(num_eigenvalues) > es.setOperators(petsc_a, petsc_m) > es.solve() > > In the fenics code you do: > > PETScOptions.set("eps_gen_non_hermitian") > PETScOptions.set("st_pc_factor_shift_type", "NONZERO") > PETScOptions.set("eps_type", "krylov") > PETScOptions.set("eps_largest_imaginary") > PETScOptions.set("eps_tol", 1e-10) > > n = 1 > eigensolver = SLEPcEigenSolver(A, M) > eigensolver.solve(int(n)) > > > So there are a bunch of differences: > > 1. You're looking for 5 eigenvalues, not 1, in the first snippet > 2. You're looking for the smallest imaginary in the first, but the > largest imaginary in the second > 3. You've set the problem type to generalized hermitian in the first, > but generalized non-hermitian in the second. > 4. You've not set eps_type in the first, but set it to "krylov" in the > second (I don't think that is a valid type, did you mean krylovschur?) > > > If I do instead: > > num_eigenvalues = 5 # Number of > eigenvalues > > # Create solver > es = SLEPc.EPS().create(comm=COMM_WORLD) > es.setDimensions(num_eigenvalues) > es.setProblemType(es.ProblemType.GNHEP) > es.setWhichEigenpairs(es.Which.LARGEST_IMAGINARY) > es.setOperators(petsc_a, petsc_m) # Build Operators > es.solve() # solve system > > I get some reasonable looking answers. > > Note that you can control things using PETSc options in the usual way > as well: > > opts = PETSc.Options() > > opts.setValue("eps_gen_non_hermitian", None) > opts.setValue("st_pc_factor_shift_type", "NONZERO") > opts.setValue("eps_type", "krylovschur") > opts.setValue("eps_largest_imaginary", None) > opts.setValue("eps_tol", 1e-10) > > es = SLEPc.EPS().create(comm=COMM_WORLD) > es.setDimensions(num_eigenvalues) > es.setOperators(petsc_a, petsc_m) > es.setFromOptions() > es.solve() > > Cheers, > > Lawrence > > > _______________________________________________ > firedrake mailing list > firedrake(a)imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/firedrake >

5 17

Dirichlet boundary issues
by William Booker 06 Dec '16

06 Dec '16

Dear Firedrakers, I'm trying to implement system (11)-(14) in the attached .pdf, but with Hcm being a Dirichlet boundary condition having a constant value 0.07 at y = 0. The solution rises uniformly, where it should dip near y = 0, and it seems to do so regardless of the BC value I choose. Which leads to me to believe that I'm not implementing it correctly. How could I fix this? Regards, Will

2 1

Re: [firedrake] Mesh refinement
by Colin Cotter 06 Dec '16

06 Dec '16

Ah ok, we'll give this a try! We can definitely wait a couple more weeks for parallel. all the best --cjc On 6 December 2016 at 13:02, Barral, Nicolas X <n.barral(a)imperial.ac.uk> wrote: > On 06/12/16 11:39, Colin Cotter wrote: > > Dear all, > > We are keen to do some adaptive mesh refinement in Firedrake, but > > probably don't need the full capabilities of Pragmatic, since we are > > just solving a time independent problem, computing an error bound and > > then refining where necessary (not coursening, and not rebalancing to > > start with). Does dmplex have any built in refinement operations that we > > can use? > > > > Cheers > > Cjc > > > > > > If you don't care about parallel (or can wait a couple more weeks), and > you already have an error bound you can turn into a metric field, the > current interface to pragmatic in petsc is very simple (and the install > process works fine): > https://www.mcs.anl.gov/petsc/petsc-dev/docs/manualpages/ > DMPLEX/DMPlexAdapt.html > > PetscErrorCode DMPlexAdapt(DM dm, Vec metric, const char bdLabelName[], > DM *dmAdapt) > it simply takes your dmplex, your metric field and gives a new dmplex. > > Advantages are it is likely to be parallel soon, and if you plan on > needing something more than refinement you won't have to change your > code. I'm not even sure it's much slower than Matt Knepley's handmade > refinement. > Drawback is it's not hierarchical refinement if you need that for some > reason. > > -- > Nicolas > > > > -- > Nicolas Barral > > Dept. of Earth Science and Engineering > Imperial College London > Royal School of Mines - Office 4.88 > London SW7 2AZ > > _______________________________________________ > 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

1 0