December 2016 - firedrake - imperial.ac.uk

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

Mesh refinement
by Colin Cotter 06 Dec '16

06 Dec '16

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 -- http://www.imperial.ac.uk/people/colin.cotter www.cambridge.org/9781107663916

3 2

trying to add new demo
by Francis Poulin 04 Dec '16

04 Dec '16

Hello, We have put together a new demo that I would like to add to the repo for people to look at. I followed my instructions from last time but seem to be missing something. I did the following: 1) cloned the Master repo, 2) created a new branch gyre_demos, 3) Added my folder 4) Committed it I tried to push it but that failed. The error I get is copied below, remote: Permission to firedrakeproject/firedrake.git denied to francispoulin. fatal: unable to access 'https://github.com/firedrakeproject/firedrake.git/': The requested URL returned error: 403 I presume this means that I can't push it because I don't have permissions to the firedrake repo. If someone can tell me how should add this demo that would be great. Thanks, 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

2 1

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

02 Dec '16

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 > > >

2 1

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

02 Dec '16

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 > > >

2 2

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

02 Dec '16

Hi Anna, Possibly but not necessarily. Two more specific questions: 1. what is the mathematical operator on third diagonal block. I.e. is it supposed to be indefinite? 2. If you set fieldsplit_n_ksp_converged_reason on for n=0,1,2,3 is it number 3 which is causing the issue? Regards, David On Fri, 2 Dec 2016 at 14:43 Anna Kalogirou <a.kalogirou(a)leeds.ac.uk> wrote: > Hi David, > > The convergence failure in the phi_solver is due to a silly mistake, > corrected by removing the solver parameters in phi (and also eta) solvers. > > Then the problem gives another convergence failure of the linear solver: > > firedrake.exceptions.ConvergenceError: Nonlinear solve failed to converge > after 0 nonlinear iterations. > Reason: > Inner linear solve failed to converge after 180 iterations with reason: > DIVERGED_DTOL > > I guess this is due to the lack of preconditioning on the 3rd block? > > Best, Anna. > > > > On 02/12/16 14:11, David Ham wrote: > > Hi Anna, > > The issue is that (at least at the moment) you can't use lu on the real > space block (that's fieldsplit_4 in your setup). You can switch this out > for a ksp_type of cg and a preconditioner of none (it's a 1 * 1 block so > from a straight maths point of view pretty much any solver will work). > > If you fix this then the solver fails to converge. > Sticking fieldsplit_n_ksp_converged_reason on for n=0,1,2,3 reveals that lu > fails on block 3 due to zero pivots. I'm not sure what this block is but > it's apparently indefinite. I replaced the solver on that block with > unpreconditioned cg too and the solver converged. That's almost certainly > not the best choice of solver for that block, but it's progress. With CG in > place, the F_solve converges. > > You then get a failure in the phi_solver. I haven't really looked into > that case, but the error message suggests that you're trying to use a field > split preconditioner on a case with only one field. > > Regards, > > David > > On Fri, 2 Dec 2016 at 12:21 Anna Kalogirou <A.Kalogirou(a)leeds.ac.uk> > wrote: > > The code is available here > <https://bitbucket.org/annakalog/buoy2d/src/02696bd962286ef8b67667c98bc1043c…>. > Note that you have to go to the directory: Buoy2D/Inequality > constraint/Mixed system. > > Thank you, > > Anna. > > > On 2 Dec 2016, at 12:10, David Ham <David.Ham(a)imperial.ac.uk> wrote: > > Hi Anna, > > Yes, you're using a preconditioner which is not legal for one of your > blocks. I suspect it's the global block. Can you push your code somewhere I > can see and I'll have a read of your PETSc options. > > Regards, > > David > > On Fri, 2 Dec 2016 at 10:04 Anna Kalogirou <a.kalogirou(a)leeds.ac.uk> > wrote: > > Dear David, > > Can advice on this error? > > File "/e/data1/users/matak/opt/firedrake/Ship/Modules/Inequality > constraint/Mixed system/solvers.py", line 182, in solvers_SV > F_solver.solve() > File > "/e/data1/users/matak/opt/firedrake-installation/firedrake/src/firedrake/firedrake/variational_solver.py", > line 196, in solve > self.snes.solve(None, v) > File "PETSc/SNES.pyx", line 537, in petsc4py.PETSc.SNES.solve > (src/petsc4py.PETSc.c:171835) > petsc4py.PETSc.Error: error code 1 > [0] SNESSolve() line 4128 in > /tmp/pip-P_wDAl-build/src/snes/interface/snes.c > [0] SNESSolve_KSPONLY() line 40 in > /tmp/pip-P_wDAl-build/src/snes/impls/ksponly/ksponly.c > [0] KSPSolve() line 677 in > /tmp/pip-P_wDAl-build/src/ksp/ksp/interface/itfunc.c > [0] KSPSolve_GMRES() line 239 in > /tmp/pip-P_wDAl-build/src/ksp/ksp/impls/gmres/gmres.c > [0] KSPInitialResidual() line 69 in > /tmp/pip-P_wDAl-build/src/ksp/ksp/interface/itres.c > [0] KSP_PCApply() line 263 in > /tmp/pip-P_wDAl-build/include/petsc/private/kspimpl.h > [0] PCApply() line 482 in > /tmp/pip-P_wDAl-build/src/ksp/pc/interface/precon.c > [0] PCApply_FieldSplit() line 996 in > /tmp/pip-P_wDAl-build/src/ksp/pc/impls/fieldsplit/fieldsplit.c > [0] KSPSolve() line 620 in > /tmp/pip-P_wDAl-build/src/ksp/ksp/interface/itfunc.c > [0] KSPSetUp() line 393 in > /tmp/pip-P_wDAl-build/src/ksp/ksp/interface/itfunc.c > [0] PCSetUp() line 968 in > /tmp/pip-P_wDAl-build/src/ksp/pc/interface/precon.c > [0] PCSetUp_LU() line 92 in > /tmp/pip-P_wDAl-build/src/ksp/pc/impls/factor/lu/lu.c > [0] MatGetOrdering() line 260 in > /tmp/pip-P_wDAl-build/src/mat/order/sorder.c > [0] MatGetOrdering_ND() line 19 in > /tmp/pip-P_wDAl-build/src/mat/order/spnd.c > [0] No support for this operation for this object type > [0] Cannot get rows for matrix type python > > Thanks, Anna. > > > > On 01/12/16 17:26, Anna Kalogirou wrote: > > Oh ok I am not using the globals_petsc_changes branch of PyOP2. I will > update again, thanks. > > Best, Anna. > > On 1 Dec 2016, at 17:22, David Ham <David.Ham(a)imperial.ac.uk> wrote: > > Hi Anna, > > I don't think that PyOP2 install is current. Are you sure you are on the > latest versions of the right branches? The most important lines from > firedrake-status are: > > |PyOP2 |globals_petsc_changes |ddca732 > |False | > |firedrake |real-function-space |e051f50 > |False | > |petsc4py |python_matrix_bug_fixes |2d3f08a > |False | > > Do your branches and revisions match the above? > > Regards, > > David > > On Thu, 1 Dec 2016 at 17:09 Anna Kalogirou <A.Kalogirou(a)leeds.ac.uk> > wrote: > > Dear David, > > I am now running into the following error message: > > Traceback (most recent call last): > File "buoy-swe.py", line 84, in <module> > F_solver = solver_F(phi0_5, eta1, lambda0_5, mu0_5, I, w, phi0, eta0, > Z0, W0, etaR, phi_t, eta_t, lambda_t, mu_t, I_t, v1, v2, v3, v4, v5, dt, > Hb, H0, L, dR_dt, lambda_bar, (2/dt)*mu_bar, g, rho, Mass, solvers_print); > File > "/Users/matak/Documents/Simulations/Firedrake/Ship/Modules/Inequality > constraint/Mixed system/solvers.py", line 52, in solver_F > F_solver = LinearVariationalSolver(F_problem, > solver_parameters=solvers_print) > File > "/Users/matak/firedrake/src/firedrake/firedrake/variational_solver.py", > line 262, in __init__ > super(LinearVariationalSolver, self).__init__(*args, **kwargs) > File > "/Users/matak/firedrake/src/firedrake/firedrake/variational_solver.py", > line 132, in __init__ > appctx=appctx) > File "/Users/matak/firedrake/src/firedrake/firedrake/solving_utils.py", > line 213, in __init__ > appctx=appctx) > File "/Users/matak/firedrake/src/firedrake/firedrake/assemble.py", line > 104, in allocate_matrix > allocate_only=True) > File "<decorator-gen-278>", line 2, in _assemble > File "/Users/matak/firedrake/src/firedrake/firedrake/utils.py", line 62, > in wrapper > return f(*args, **kwargs) > File "/Users/matak/firedrake/src/firedrake/firedrake/assemble.py", line > 261, in _assemble > "%s_%s_matrix" % fs_names) > File "/Users/matak/firedrake/src/firedrake/firedrake/matrix.py", line > 152, in __init__ > self._M = op2.Mat(*args, **kwargs) > File "/Users/matak/firedrake/src/PyOP2/pyop2/petsc_base.py", line 626, > in __init__ > self._init() > File "/Users/matak/firedrake/src/PyOP2/pyop2/petsc_base.py", line 637, > in _init > self._init_nest() > File "/Users/matak/firedrake/src/PyOP2/pyop2/petsc_base.py", line 696, > in _init_nest > '_'.join([self.name, str(i), str(j)]))) > File "/Users/matak/firedrake/src/PyOP2/pyop2/petsc_base.py", line 626, > in __init__ > self._init() > File "/Users/matak/firedrake/src/PyOP2/pyop2/petsc_base.py", line 642, > in _init > self._init_block() > File "/Users/matak/firedrake/src/PyOP2/pyop2/petsc_base.py", line 709, > in _init_block > self._init_global_block() > File "/Users/matak/firedrake/src/PyOP2/pyop2/petsc_base.py", line 773, > in _init_global_block > self._version_set_zero() > AttributeError: 'Mat' object has no attribute '_version_set_zero' > > Here is the relevant part of the code: > > aphi = v1*(phi - lambda_t)*dx > Lphi = v1*(phi0 - 0.5*dt*g*(eta0-etaR))*dx > > aeta = (v2*eta - dt*Hb*inner(grad(v2),grad(phi)))*dx > Leta = v2*eta0*dx + dt*H0*dR_dt*v2*ds(1) #ds_v(1) > > alambda = v3*(eta/dt + rho/Mass*I_t + mu_bar*mu_t)*dx > Llambda = v3*(Z0/dt + W0)*dx > > amu = v4*(mu_bar*lambda_t + lambda_bar*mu_t)*dx > > aI = v5*(I_t/L-lambda_t)*dx > > a_solve = aphi + aeta + alambda + amu + aI > L_solve = Lphi + Leta + Llambda > > Ap = v1*phi*dx + Hb*inner(grad(v1),grad(phi))*dx \ > + v2*eta*dx \ > + v3*(rho/Mass-mu_bar**2)*lambda_t*dx \ > + v4*lambda_bar*mu_t*dx \ > + v5*1.0/L*I_t*dx > > F_problem = LinearVariationalProblem(a_solve, L_solve, w, aP=Ap) > F_solver = LinearVariationalSolver(F_problem, > solver_parameters=solvers_print) > > Thank you, > > Anna. > > On 7 Nov 2016, at 17:23, David Ham <david.ham(a)imperial.ac.uk> wrote: > > Yes. This is because trace elements were very recently (after my email) > merged into other components of Firedrake and the globals branch needs to > catch up. > > I've just pushed the relevant commits to the real-function-space branch so > that might work now. > > Regards, > > David > > > On Mon, 7 Nov 2016 at 17:15 Anna Kalogirou <a.kalogirou(a)leeds.ac.uk> > wrote: > > Dear David, > > I have just updated firedrake using the branches you mention in the email > below but I now get some error related to the mesh (?), when running > various codes which were previously working. Any idea what this is? > > Thanks, Anna. > > > File > "/e/data1/users/matak/opt/firedrake-installation/firedrake/src/firedrake/firedrake/functionspace.py", > line 42, in make_scalar_element > mesh.init() > File > "/e/data1/users/matak/opt/firedrake-installation/firedrake/src/firedrake/firedrake/mesh.py", > line 898, in init > self._callback(self) > File > "/e/data1/users/matak/opt/firedrake-installation/firedrake/src/firedrake/firedrake/mesh.py", > line 1245, in callback > dim=geometric_dim) > File > "/e/data1/users/matak/opt/firedrake-installation/firedrake/src/firedrake/firedrake/functionspace.py", > line 174, in VectorFunctionSpace > return FunctionSpace(mesh, element, name=name) > File "<decorator-gen-280>", line 2, in FunctionSpace > File > "/e/data1/users/matak/opt/firedrake-installation/firedrake/src/PyOP2/pyop2/profiling.py", > line 59, in wrapper > return f(*args, **kwargs) > File > "/e/data1/users/matak/opt/firedrake-installation/firedrake/src/firedrake/firedrake/functionspace.py", > line 127, in FunctionSpace > check_element(element) > File > "/e/data1/users/matak/opt/firedrake-installation/firedrake/src/firedrake/firedrake/functionspace.py", > line 85, in check_element > ufl.TraceElement, ufl.HDivElement, ufl.HCurlElement): > AttributeError: 'module' object has no attribute 'TraceElement' > > > > > On 04/11/16 16:16, David Ham wrote: > > A brief status update on this: the real-function-spaces branch of > Firedrake taken together with the globals_petsc_changes branch of PyOP2 no > longer exhibits the direct crash observed. However I am also yet to > actually successfully solve using a block preconditioner. I need to consult > with Lawrence to establish whether the problem is another bug or pilot > error. > > Regards, > > David > > On Mon, 24 Oct 2016 at 11:37 Mitchell, Lawrence < > lawrence.mitchell(a)imperial.ac.uk> wrote: > > > > On 24 Oct 2016, at 11:13, Anna Kalogirou <A.Kalogirou(a)leeds.ac.uk> > wrote: > > > > Hi Lawrence, > > > > Any update regarding the bug reported below? > > This appears to be more involved than I had first thought. So no luck > yet, sorry! David and I need to find some time together to work out the > differences/corner cases. > > Cheers, > > 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 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 > > >

3 5