On Fri, 2 Dec 2016 at 17:36 Anna Kalogirou <a.kalogirou@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@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@imperial.ac.uk> wrote:
On Fri, 2 Dec 2016 at 16:12 Mitchell, Lawrence < lawrence.mitchell@imperial.ac.uk> wrote:
On 2 Dec 2016, at 16:01, Anna Kalogirou <a.kalogirou@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@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
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@leeds.ac.uk <mailto:a.kalogirou@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@leeds.ac.uk <mailto:a.kalogirou@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@imperial.ac.uk <mailto:David.Ham@imperial.ac.uk>> wrote:
On Fri, 2 Dec 2016 at 16:12 Mitchell, Lawrence <lawrence.mitchell@imperial.ac.uk <mailto:lawrence.mitchell@imperial.ac.uk>> wrote:
> On 2 Dec 2016, at 16:01, Anna Kalogirou <a.kalogirou@leeds.ac.uk <mailto:a.kalogirou@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@imperial.ac.uk <mailto:firedrake@imperial.ac.uk> https://mailman.ic.ac.uk/mailman/listinfo/firedrake
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk <mailto:firedrake@imperial.ac.uk> https://mailman.ic.ac.uk/mailman/listinfo/firedrake
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk <mailto:firedrake@imperial.ac.uk> https://mailman.ic.ac.uk/mailman/listinfo/firedrake
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
participants (2)
-
Anna Kalogirou
-
David Ham