<div dir="ltr">Hi Lukasz, thanks for sharing very interesting slide.<div><br></div><div>Both of you are right, the mortar method starts from continuum argument then reduce to discrete space by discretizing the Lagrange multiplier. However, the way to choose the interpolation space has some implication on the properties of the mortar matrices. For example, the dual mortar space can help to reduce the multiplier by static condensation but it creates some numerical oscillation. In my opinion I think it's not stable despite a very sound theoretical foundation is developed. Both standard and dual mortar approach impose some drawbacks for high order contact because of negative shape function can create some spurious negative nodal gap. How do you cope with that case in your code?</div><div><br></div><div>However, this question may be a bit off-topic. Come back to the main question, for mesh "gluing" using mortar method, the Schur matrix is S=[0 -D^T M^T] A^-1 [0 D M]^T, has the form of A_10 (A_00)^-1 A01 since A_11=0. The magnitude of S (~E^-1) is too small compare to A_00 (which is ~E for elasticity). I think in some case it's also rank deficient if three Lagrange multiplier is used per node (S is very ill-conditioned although A_00 is well). I'm skeptical here do you really solve the system of mortar with schur complement?</div><div class="gmail_extra"><br clear="all"><div><div class="m_8426486426086775844m_2348089183134207201gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Giang</div></div></div>
<br><div class="gmail_quote">On Wed, May 3, 2017 at 2:55 PM, Lukasz Kaczmarczyk <span dir="ltr"><<a href="mailto:Lukasz.Kaczmarczyk@glasgow.ac.uk" target="_blank">Lukasz.Kaczmarczyk@glasgow.ac<wbr>.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<br>
<div><span>
<blockquote type="cite">
<div>On 3 May 2017, at 13:22, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:</div>
<br class="m_8426486426086775844m_2348089183134207201m_7797658317358904813Apple-interchange-newline">
<div>
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div class="gmail_extra">
<div class="gmail_quote">On Wed, May 3, 2017 at 2:29 AM, Hoang Giang Bui<span class="m_8426486426086775844m_2348089183134207201m_7797658317358904813Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:hgbk2008@gmail.com" target="_blank">hgbk2008@gmail.com</a>></span><span class="m_8426486426086775844m_2348089183134207201m_7797658317358904813Apple-converted-space"> </span>wrote<wbr>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Dear Jed
<div><br>
</div>
<div>If I understood you correctly you suggest to avoid penalty by using the Lagrange multiplier for the mortar constraint? In this case it leads to the use of discrete Lagrange multiplier space.</div>
</div>
</blockquote>
<div><br>
</div>
<div>Sorry for being ignorant here, but why is the space "discrete"? It looks like you should have a continuum formulation</div>
<div>of the mortar as well. Maybe I do not understand something fundamental. From this (<a href="https://en.wikipedia.org/wiki/Mortar_methods" target="_blank">https://en.wikipedia.org/wiki<wbr>/Mortar_methods</a>)</div>
<div>short description, it seems that mortars begin from a continuum formulation, but are then reduced to the discrete level. This is no</div>
<div>problem if done consistently, as for instance in the FETI method where efficient preconditioners exist.</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span><div>
<div>Hello,</div>
<div><br>
</div>
<div>
<div>I copied the wrong link to mortar method, how we implemented it, see presentation <a href="http://doi.org/10.5281/zenodo.556996" target="_blank">http://doi.org/10<wbr>.5281/zenodo.556996</a></div>
<div><br>
</div>
<div>You right that we always start from continuum formulation, on this we apply some discretisation, at the end Lagrange multiplier is expressed by a finite vector of discrete unknowns. It is better to formulate problem first for the continuum; you
have better control on what you are doing and stability of the solution.</div>
<div><br>
</div>
<div>Of course, you can add some constraints at the discreet level, after you discretised problem, but implicitly you have some continuous space for Lagrange multipliers, which is associated with shape functions which you use to discretise problem.</div>
<div><br>
</div>
<div>In our problem which we have, we try to avoid rebuilding of the system of equations each time contact area is changing. We going to construct DM sub-problem for each body in contact, each sub-problem going to be solved using MG (adjacency for
those matrices is fixed in time). All will go to put in nested matrix with the separate block for Lagrange multipliers (adjacency will change in each time step). For solving Lagrange multipliers we going to use FIELDSPLIT using Schur complement. I need
to look more detail to FETI method, at are still at development stage for contact problem and direct solver works, for now, small problems at that point.</div>
<div><br>
</div>
<div>In our code, we using higher order elements with hierarchical base, for this we using specialise MG solver, as you can see here, it works pretty well for moderate size problems, <100M</div>
<div><a href="http://mofem.eng.gla.ac.uk/mofem/html/_p_c_m_g_set_up_via_approx_orders_8cpp.html" target="_blank">http://mofem.eng.gla.ac.uk/mof<wbr>em/html/_p_c_m_g_set_up_via_ap<wbr>prox_orders_8cpp.html</a></div>
<div><br>
</div>
<div>Regards,</div>
<div>Lukasz</div>
</div>
</div><div><div class="m_8426486426086775844m_2348089183134207201h5">
<div><br>
</div>
<div><br>
</div>
<br>
<blockquote type="cite">
<div>
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div class="gmail_extra">
<div class="gmail_quote">
<div> Thanks,</div>
<div><br>
</div>
<div> Matt</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>Do you or anyone already have experience using discrete Lagrange multiplier space with Petsc?</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">There is also similar question on stackexchange</div>
<div class="gmail_extra"><a href="https://scicomp.stackexchange.com/questions/25113/preconditioners-and-discrete-lagrange-multipliers" target="_blank">https://scicomp.stackexchange.<wbr>com/questions/25113/preconditi<wbr>oners-and-discrete-lagrange-mu<wbr>ltipliers</a><br>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="m_8426486426086775844m_2348089183134207201m_7797658317358904813gmail-m_6948412756754771881gmail_signature">
<div dir="ltr">Giang</div>
</div>
</div>
<br>
<div class="gmail_quote">On Sat, Apr 29, 2017 at 3:34 PM, Jed Brown<span class="m_8426486426086775844m_2348089183134207201m_7797658317358904813Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span><span class="m_8426486426086775844m_2348089183134207201m_7797658317358904813Apple-converted-space"> </span>wrote<wbr>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span class="m_8426486426086775844m_2348089183134207201m_7797658317358904813gmail-m_6948412756754771881gmail-">Hoang Giang Bui <<a href="mailto:hgbk2008@gmail.com" target="_blank">hgbk2008@gmail.com</a>> writes:<br>
<br>
> Hi Barry<br>
><br>
> The first block is from a standard solid mechanics discretization based on<br>
> balance of momentum equation. There is some material involved but in<br>
> principal it's well-posed elasticity equation with positive definite<br>
> tangent operator. The "gluing business" uses the mortar method to keep the<br>
> continuity of displacement. Instead of using Lagrange multiplier to treat<br>
> the constraint I used penalty method to penalize the energy. The<br>
> discretization form of mortar is quite simple<br>
><br>
> \int_{\Gamma_1} { rho * (\delta u_1 - \delta u_2) * (u_1 - u_2) dA }<br>
><br>
> rho is penalty parameter. In the simulation I initially set it low (~E) to<br>
> preserve the conditioning of the system.<br>
<br>
</span>There are two things that can go wrong here with AMG:<br>
<br>
* The penalty term can mess up the strength of connection heuristics<br>
such that you get poor choice of C-points (classical AMG like<br>
BoomerAMG) or poor choice of aggregates (smoothed aggregation).<br>
<br>
* The penalty term can prevent Jacobi smoothing from being effective; in<br>
this case, it can lead to poor coarse basis functions (higher energy<br>
than they should be) and poor smoothing in an MG cycle. You can fix<br>
the poor smoothing in the MG cycle by using a stronger smoother, like<br>
ASM with some overlap.<br>
<br>
I'm generally not a fan of penalty methods due to the irritating<br>
tradeoffs and often poor solver performance.<br>
<span class="m_8426486426086775844m_2348089183134207201m_7797658317358904813gmail-m_6948412756754771881gmail-"><br>
> In the figure below, the colorful blocks are u_1 and the base is u_2. Both<br>
> u_1 and u_2 use isoparametric quadratic approximation.<br>
><br>
> <br>
</span>> Snapshot.png<br>
> <<a href="https://drive.google.com/file/d/0Bw8Hmu0-YGQXc2hKQ1BhQ1I4OEU/view?usp=drive_web" rel="noreferrer" target="_blank">https://drive.google.com/file<wbr>/d/0Bw8Hmu0-YGQXc2hKQ1BhQ1I4OE<wbr>U/view?usp=drive_web</a>><br>
<div class="m_8426486426086775844m_2348089183134207201m_7797658317358904813gmail-m_6948412756754771881gmail-HOEnZb">
<div class="m_8426486426086775844m_2348089183134207201m_7797658317358904813gmail-m_6948412756754771881gmail-h5">> <br>
><br>
> Giang<br>
><br>
> On Fri, Apr 28, 2017 at 6:21 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
>><br>
>> Ok, so boomerAMG algebraic multigrid is not good for the first block.<br>
>> You mentioned the first block has two things glued together? AMG is<br>
>> fantastic for certain problems but doesn't work for everything.<br>
>><br>
>> Tell us more about the first block, what PDE it comes from, what<br>
>> discretization, and what the "gluing business" is and maybe we'll have<br>
>> suggestions for how to precondition it.<br>
>><br>
>> Barry<br>
>><br>
>> > On Apr 28, 2017, at 3:56 AM, Hoang Giang Bui <<a href="mailto:hgbk2008@gmail.com" target="_blank">hgbk2008@gmail.com</a>> wrote:<br>
>> ><br>
>> > It's in fact quite good<br>
>> ><br>
>> > Residual norms for fieldsplit_u_ solve.<br>
>> > 0 KSP Residual norm 4.014715925568e+00<br>
>> > 1 KSP Residual norm 2.160497019264e-10<br>
>> > Residual norms for fieldsplit_wp_ solve.<br>
>> > 0 KSP Residual norm 0.000000000000e+00<br>
>> > 0 KSP preconditioned resid norm 4.014715925568e+00 true resid norm<br>
>> 9.006493082896e+06 ||r(i)||/||b|| 1.000000000000e+00<br>
>> > Residual norms for fieldsplit_u_ solve.<br>
>> > 0 KSP Residual norm 9.999999999416e-01<br>
>> > 1 KSP Residual norm 7.118380416383e-11<br>
>> > Residual norms for fieldsplit_wp_ solve.<br>
>> > 0 KSP Residual norm 0.000000000000e+00<br>
>> > 1 KSP preconditioned resid norm 1.701150951035e-10 true resid norm<br>
>> 5.494262251846e-04 ||r(i)||/||b|| 6.100334726599e-11<br>
>> > Linear solve converged due to CONVERGED_ATOL iterations 1<br>
>> ><br>
>> > Giang<br>
>> ><br>
>> > On Thu, Apr 27, 2017 at 5:25 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
>> ><br>
>> > Run again using LU on both blocks to see what happens.<br>
>> ><br>
>> ><br>
>> > > On Apr 27, 2017, at 2:14 AM, Hoang Giang Bui <<a href="mailto:hgbk2008@gmail.com" target="_blank">hgbk2008@gmail.com</a>><br>
>> wrote:<br>
>> > ><br>
>> > > I have changed the way to tie the nonconforming mesh. It seems the<br>
>> matrix now is better<br>
>> > ><br>
>> > > with -pc_type lu the output is<br>
>> > > 0 KSP preconditioned resid norm 3.308678584240e-01 true resid norm<br>
>> 9.006493082896e+06 ||r(i)||/||b|| 1.000000000000e+00<br>
>> > > 1 KSP preconditioned resid norm 2.004313395301e-12 true resid norm<br>
>> 2.549872332830e-05 ||r(i)||/||b|| 2.831148938173e-12<br>
>> > > Linear solve converged due to CONVERGED_ATOL iterations 1<br>
>> > ><br>
>> > ><br>
>> > > with -pc_type fieldsplit -fieldsplit_u_pc_type hypre<br>
>> -fieldsplit_wp_pc_type lu the convergence is slow<br>
>> > > 0 KSP preconditioned resid norm 1.116302362553e-01 true resid norm<br>
>> 9.006493083520e+06 ||r(i)||/||b|| 1.000000000000e+00<br>
>> > > 1 KSP preconditioned resid norm 2.582134825666e-02 true resid norm<br>
>> 9.268347719866e+06 ||r(i)||/||b|| 1.029073984060e+00<br>
>> > > ...<br>
>> > > 824 KSP preconditioned resid norm 1.018542387738e-09 true resid norm<br>
>> 2.906608839310e+02 ||r(i)||/||b|| 3.227237074804e-05<br>
>> > > 825 KSP preconditioned resid norm 9.743727947637e-10 true resid norm<br>
>> 2.820369993061e+02 ||r(i)||/||b|| 3.131485215062e-05<br>
>> > > Linear solve converged due to CONVERGED_ATOL iterations 825<br>
>> > ><br>
>> > > checking with additional -fieldsplit_u_ksp_type richardson<br>
>> -fieldsplit_u_ksp_monitor -fieldsplit_u_ksp_max_it 1<br>
>> -fieldsplit_wp_ksp_type richardson -fieldsplit_wp_ksp_monitor<br>
>> -fieldsplit_wp_ksp_max_it 1 gives<br>
>> > ><br>
>> > > 0 KSP preconditioned resid norm 1.116302362553e-01 true resid norm<br>
>> 9.006493083520e+06 ||r(i)||/||b|| 1.000000000000e+00<br>
>> > > Residual norms for fieldsplit_u_ solve.<br>
>> > > 0 KSP Residual norm 5.803507549280e-01<br>
>> > > 1 KSP Residual norm 2.069538175950e-01<br>
>> > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > 0 KSP Residual norm 0.000000000000e+00<br>
>> > > 1 KSP preconditioned resid norm 2.582134825666e-02 true resid norm<br>
>> 9.268347719866e+06 ||r(i)||/||b|| 1.029073984060e+00<br>
>> > > Residual norms for fieldsplit_u_ solve.<br>
>> > > 0 KSP Residual norm 7.831796195225e-01<br>
>> > > 1 KSP Residual norm 1.734608520110e-01<br>
>> > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > 0 KSP Residual norm 0.000000000000e+00<br>
>> > > ....<br>
>> > > 823 KSP preconditioned resid norm 1.065070135605e-09 true resid norm<br>
>> 3.081881356833e+02 ||r(i)||/||b|| 3.421843916665e-05<br>
>> > > Residual norms for fieldsplit_u_ solve.<br>
>> > > 0 KSP Residual norm 6.113806394327e-01<br>
>> > > 1 KSP Residual norm 1.535465290944e-01<br>
>> > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > 0 KSP Residual norm 0.000000000000e+00<br>
>> > > 824 KSP preconditioned resid norm 1.018542387746e-09 true resid norm<br>
>> 2.906608839353e+02 ||r(i)||/||b|| 3.227237074851e-05<br>
>> > > Residual norms for fieldsplit_u_ solve.<br>
>> > > 0 KSP Residual norm 6.123437055586e-01<br>
>> > > 1 KSP Residual norm 1.524661826133e-01<br>
>> > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > 0 KSP Residual norm 0.000000000000e+00<br>
>> > > 825 KSP preconditioned resid norm 9.743727947718e-10 true resid norm<br>
>> 2.820369990571e+02 ||r(i)||/||b|| 3.131485212298e-05<br>
>> > > Linear solve converged due to CONVERGED_ATOL iterations 825<br>
>> > ><br>
>> > ><br>
>> > > The residual for wp block is zero since in this first step the rhs is<br>
>> zero. As can see in the output, the multigrid does not perform well to<br>
>> reduce the residual in the sub-solve. Is my observation right? what can be<br>
>> done to improve this?<br>
>> > ><br>
>> > ><br>
>> > > Giang<br>
>> > ><br>
>> > > On Tue, Apr 25, 2017 at 12:17 AM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>><br>
>> wrote:<br>
>> > ><br>
>> > > This can happen in the matrix is singular or nearly singular or if<br>
>> the factorization generates small pivots, which can occur for even<br>
>> nonsingular problems if the matrix is poorly scaled or just plain nasty.<br>
>> > ><br>
>> > ><br>
>> > > > On Apr 24, 2017, at 5:10 PM, Hoang Giang Bui <<a href="mailto:hgbk2008@gmail.com" target="_blank">hgbk2008@gmail.com</a>><br>
>> wrote:<br>
>> > > ><br>
>> > > > It took a while, here I send you the output<br>
>> > > ><br>
>> > > > 0 KSP preconditioned resid norm 3.129073545457e+05 true resid norm<br>
>> 9.015150492169e+06 ||r(i)||/||b|| 1.000000000000e+00<br>
>> > > > 1 KSP preconditioned resid norm 7.442444222843e-01 true resid norm<br>
>> 1.003356247696e+02 ||r(i)||/||b|| 1.112966720375e-05<br>
>> > > > 2 KSP preconditioned resid norm 3.267453132529e-07 true resid norm<br>
>> 3.216722968300e+01 ||r(i)||/||b|| 3.568130084011e-06<br>
>> > > > 3 KSP preconditioned resid norm 1.155046883816e-11 true resid norm<br>
>> 3.234460376820e+01 ||r(i)||/||b|| 3.587805194854e-06<br>
>> > > > Linear solve converged due to CONVERGED_ATOL iterations 3<br>
>> > > > KSP Object: 4 MPI processes<br>
>> > > > type: gmres<br>
>> > > > GMRES: restart=1000, using Modified Gram-Schmidt<br>
>> Orthogonalization<br>
>> > > > GMRES: happy breakdown tolerance 1e-30<br>
>> > > > maximum iterations=1000, initial guess is zero<br>
>> > > > tolerances: relative=1e-20, absolute=1e-09, divergence=10000<br>
>> > > > left preconditioning<br>
>> > > > using PRECONDITIONED norm type for convergence test<br>
>> > > > PC Object: 4 MPI processes<br>
>> > > > type: lu<br>
>> > > > LU: out-of-place factorization<br>
>> > > > tolerance for zero pivot 2.22045e-14<br>
>> > > > matrix ordering: natural<br>
>> > > > factor fill ratio given 0, needed 0<br>
>> > > > Factored matrix follows:<br>
>> > > > Mat Object: 4 MPI processes<br>
>> > > > type: mpiaij<br>
>> > > > rows=973051, cols=973051<br>
>> > > > package used to perform factorization: pastix<br>
>> > > > Error : 3.24786e-14<br>
>> > > > total: nonzeros=0, allocated nonzeros=0<br>
>> > > > total number of mallocs used during MatSetValues calls =0<br>
>> > > > PaStiX run parameters:<br>
>> > > > Matrix type : Unsymmetric<br>
>> > > > Level of printing (0,1,2): 0<br>
>> > > > Number of refinements iterations : 3<br>
>> > > > Error : 3.24786e-14<br>
>> > > > linear system matrix = precond matrix:<br>
>> > > > Mat Object: 4 MPI processes<br>
>> > > > type: mpiaij<br>
>> > > > rows=973051, cols=973051<br>
>> > > > Error : 3.24786e-14<br>
>> > > > total: nonzeros=9.90037e+07, allocated nonzeros=9.90037e+07<br>
>> > > > total number of mallocs used during MatSetValues calls =0<br>
>> > > > using I-node (on process 0) routines: found 78749 nodes, limit<br>
>> used is 5<br>
>> > > > Error : 3.24786e-14<br>
>> > > ><br>
>> > > > It doesn't do as you said. Something is not right here. I will look<br>
>> in depth.<br>
>> > > ><br>
>> > > > Giang<br>
>> > > ><br>
>> > > > On Mon, Apr 24, 2017 at 8:21 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>><br>
>> wrote:<br>
>> > > ><br>
>> > > > > On Apr 24, 2017, at 12:47 PM, Hoang Giang Bui <<a href="mailto:hgbk2008@gmail.com" target="_blank">hgbk2008@gmail.com</a>><br>
>> wrote:<br>
>> > > > ><br>
>> > > > > Good catch. I get this for the very first step, maybe at that time<br>
>> the rhs_w is zero.<br>
>> > > ><br>
>> > > > With the multiplicative composition the right hand side of the<br>
>> second solve is the initial right hand side of the second solve minus<br>
>> A_10*x where x is the solution to the first sub solve and A_10 is the lower<br>
>> left block of the outer matrix. So unless both the initial right hand side<br>
>> has a zero for the second block and A_10 is identically zero the right hand<br>
>> side for the second sub solve should not be zero. Is A_10 == 0?<br>
>> > > ><br>
>> > > ><br>
>> > > > > In the later step, it shows 2 step convergence<br>
>> > > > ><br>
>> > > > > Residual norms for fieldsplit_u_ solve.<br>
>> > > > > 0 KSP Residual norm 3.165886479830e+04<br>
>> > > > > 1 KSP Residual norm 2.905922877684e-01<br>
>> > > > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > > > 0 KSP Residual norm 2.397669419027e-01<br>
>> > > > > 1 KSP Residual norm 0.000000000000e+00<br>
>> > > > > 0 KSP preconditioned resid norm 3.165886479920e+04 true resid<br>
>> norm 7.963616922323e+05 ||r(i)||/||b|| 1.000000000000e+00<br>
>> > > > > Residual norms for fieldsplit_u_ solve.<br>
>> > > > > 0 KSP Residual norm 9.999891813771e-01<br>
>> > > > > 1 KSP Residual norm 1.512000395579e-05<br>
>> > > > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > > > 0 KSP Residual norm 8.192702188243e-06<br>
>> > > > > 1 KSP Residual norm 0.000000000000e+00<br>
>> > > > > 1 KSP preconditioned resid norm 5.252183822848e-02 true resid<br>
>> norm 7.135927677844e+04 ||r(i)||/||b|| 8.960661653427e-02<br>
>> > > ><br>
>> > > > The outer residual norms are still wonky, the preconditioned<br>
>> residual norm goes from 3.165886479920e+04 to 5.252183822848e-02 which is a<br>
>> huge drop but the 7.963616922323e+05 drops very much less<br>
>> 7.135927677844e+04. This is not normal.<br>
>> > > ><br>
>> > > > What if you just use -pc_type lu for the entire system (no<br>
>> fieldsplit), does the true residual drop to almost zero in the first<br>
>> iteration (as it should?). Send the output.<br>
>> > > ><br>
>> > > ><br>
>> > > ><br>
>> > > > > Residual norms for fieldsplit_u_ solve.<br>
>> > > > > 0 KSP Residual norm 6.946213936597e-01<br>
>> > > > > 1 KSP Residual norm 1.195514007343e-05<br>
>> > > > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > > > 0 KSP Residual norm 1.025694497535e+00<br>
>> > > > > 1 KSP Residual norm 0.000000000000e+00<br>
>> > > > > 2 KSP preconditioned resid norm 8.785709535405e-03 true resid<br>
>> norm 1.419341799277e+04 ||r(i)||/||b|| 1.782282866091e-02<br>
>> > > > > Residual norms for fieldsplit_u_ solve.<br>
>> > > > > 0 KSP Residual norm 7.255149996405e-01<br>
>> > > > > 1 KSP Residual norm 6.583512434218e-06<br>
>> > > > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > > > 0 KSP Residual norm 1.015229700337e+00<br>
>> > > > > 1 KSP Residual norm 0.000000000000e+00<br>
>> > > > > 3 KSP preconditioned resid norm 7.110407712709e-04 true resid<br>
>> norm 5.284940654154e+02 ||r(i)||/||b|| 6.636357205153e-04<br>
>> > > > > Residual norms for fieldsplit_u_ solve.<br>
>> > > > > 0 KSP Residual norm 3.512243341400e-01<br>
>> > > > > 1 KSP Residual norm 2.032490351200e-06<br>
>> > > > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > > > 0 KSP Residual norm 1.282327290982e+00<br>
>> > > > > 1 KSP Residual norm 0.000000000000e+00<br>
>> > > > > 4 KSP preconditioned resid norm 3.482036620521e-05 true resid<br>
>> norm 4.291231924307e+01 ||r(i)||/||b|| 5.388546393133e-05<br>
>> > > > > Residual norms for fieldsplit_u_ solve.<br>
>> > > > > 0 KSP Residual norm 3.423609338053e-01<br>
>> > > > > 1 KSP Residual norm 4.213703301972e-07<br>
>> > > > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > > > 0 KSP Residual norm 1.157384757538e+00<br>
>> > > > > 1 KSP Residual norm 0.000000000000e+00<br>
>> > > > > 5 KSP preconditioned resid norm 1.203470314534e-06 true resid<br>
>> norm 4.544956156267e+00 ||r(i)||/||b|| 5.707150658550e-06<br>
>> > > > > Residual norms for fieldsplit_u_ solve.<br>
>> > > > > 0 KSP Residual norm 3.838596289995e-01<br>
>> > > > > 1 KSP Residual norm 9.927864176103e-08<br>
>> > > > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > > > 0 KSP Residual norm 1.066298905618e+00<br>
>> > > > > 1 KSP Residual norm 0.000000000000e+00<br>
>> > > > > 6 KSP preconditioned resid norm 3.331619244266e-08 true resid<br>
>> norm 2.821511729024e+00 ||r(i)||/||b|| 3.543002829675e-06<br>
>> > > > > Residual norms for fieldsplit_u_ solve.<br>
>> > > > > 0 KSP Residual norm 4.624964188094e-01<br>
>> > > > > 1 KSP Residual norm 6.418229775372e-08<br>
>> > > > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > > > 0 KSP Residual norm 9.800784311614e-01<br>
>> > > > > 1 KSP Residual norm 0.000000000000e+00<br>
>> > > > > 7 KSP preconditioned resid norm 8.788046233297e-10 true resid<br>
>> norm 2.849209671705e+00 ||r(i)||/||b|| 3.577783436215e-06<br>
>> > > > > Linear solve converged due to CONVERGED_ATOL iterations 7<br>
>> > > > ><br>
>> > > > > The outer operator is an explicit matrix.<br>
>> > > > ><br>
>> > > > > Giang<br>
>> > > > ><br>
>> > > > > On Mon, Apr 24, 2017 at 7:32 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>><br>
>> wrote:<br>
>> > > > ><br>
>> > > > > > On Apr 24, 2017, at 3:16 AM, Hoang Giang Bui <<a href="mailto:hgbk2008@gmail.com" target="_blank">hgbk2008@gmail.com</a>><br>
>> wrote:<br>
>> > > > > ><br>
>> > > > > > Thanks Barry, trying with -fieldsplit_u_type lu gives better<br>
>> convergence. I still used 4 procs though, probably with 1 proc it should<br>
>> also be the same.<br>
>> > > > > ><br>
>> > > > > > The u block used a Nitsche-type operator to connect two<br>
>> non-matching domains. I don't think it will leave some rigid body motion<br>
>> leads to not sufficient constraints. Maybe you have other idea?<br>
>> > > > > ><br>
>> > > > > > Residual norms for fieldsplit_u_ solve.<br>
>> > > > > > 0 KSP Residual norm 3.129067184300e+05<br>
>> > > > > > 1 KSP Residual norm 5.906261468196e-01<br>
>> > > > > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > > > > 0 KSP Residual norm 0.000000000000e+00<br>
>> > > > ><br>
>> > > > > ^^^^ something is wrong here. The sub solve should not be<br>
>> starting with a 0 residual (this means the right hand side for this sub<br>
>> solve is zero which it should not be).<br>
>> > > > ><br>
>> > > > > > FieldSplit with MULTIPLICATIVE composition: total splits = 2<br>
>> > > > ><br>
>> > > > ><br>
>> > > > > How are you providing the outer operator? As an explicit matrix<br>
>> or with some shell matrix?<br>
>> > > > ><br>
>> > > > ><br>
>> > > > ><br>
>> > > > > > 0 KSP preconditioned resid norm 3.129067184300e+05 true resid<br>
>> norm 9.015150492169e+06 ||r(i)||/||b|| 1.000000000000e+00<br>
>> > > > > > Residual norms for fieldsplit_u_ solve.<br>
>> > > > > > 0 KSP Residual norm 9.999955993437e-01<br>
>> > > > > > 1 KSP Residual norm 4.019774691831e-06<br>
>> > > > > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > > > > 0 KSP Residual norm 0.000000000000e+00<br>
>> > > > > > 1 KSP preconditioned resid norm 5.003913641475e-01 true resid<br>
>> norm 4.692996324114e+01 ||r(i)||/||b|| 5.205677185522e-06<br>
>> > > > > > Residual norms for fieldsplit_u_ solve.<br>
>> > > > > > 0 KSP Residual norm 1.000012180204e+00<br>
>> > > > > > 1 KSP Residual norm 1.017367950422e-05<br>
>> > > > > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > > > > 0 KSP Residual norm 0.000000000000e+00<br>
>> > > > > > 2 KSP preconditioned resid norm 2.330910333756e-07 true resid<br>
>> norm 3.474855463983e+01 ||r(i)||/||b|| 3.854461960453e-06<br>
>> > > > > > Residual norms for fieldsplit_u_ solve.<br>
>> > > > > > 0 KSP Residual norm 1.000004200085e+00<br>
>> > > > > > 1 KSP Residual norm 6.231613102458e-06<br>
>> > > > > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > > > > 0 KSP Residual norm 0.000000000000e+00<br>
>> > > > > > 3 KSP preconditioned resid norm 8.671259838389e-11 true resid<br>
>> norm 3.545103468011e+01 ||r(i)||/||b|| 3.932384125024e-06<br>
>> > > > > > Linear solve converged due to CONVERGED_ATOL iterations 3<br>
>> > > > > > KSP Object: 4 MPI processes<br>
>> > > > > > type: gmres<br>
>> > > > > > GMRES: restart=1000, using Modified Gram-Schmidt<br>
>> Orthogonalization<br>
>> > > > > > GMRES: happy breakdown tolerance 1e-30<br>
>> > > > > > maximum iterations=1000, initial guess is zero<br>
>> > > > > > tolerances: relative=1e-20, absolute=1e-09, divergence=10000<br>
>> > > > > > left preconditioning<br>
>> > > > > > using PRECONDITIONED norm type for convergence test<br>
>> > > > > > PC Object: 4 MPI processes<br>
>> > > > > > type: fieldsplit<br>
>> > > > > > FieldSplit with MULTIPLICATIVE composition: total splits = 2<br>
>> > > > > > Solver info for each split is in the following KSP objects:<br>
>> > > > > > Split number 0 Defined by IS<br>
>> > > > > > KSP Object: (fieldsplit_u_) 4 MPI processes<br>
>> > > > > > type: richardson<br>
>> > > > > > Richardson: damping factor=1<br>
>> > > > > > maximum iterations=1, initial guess is zero<br>
>> > > > > > tolerances: relative=1e-05, absolute=1e-50,<br>
>> divergence=10000<br>
>> > > > > > left preconditioning<br>
>> > > > > > using PRECONDITIONED norm type for convergence test<br>
>> > > > > > PC Object: (fieldsplit_u_) 4 MPI processes<br>
>> > > > > > type: lu<br>
>> > > > > > LU: out-of-place factorization<br>
>> > > > > > tolerance for zero pivot 2.22045e-14<br>
>> > > > > > matrix ordering: natural<br>
>> > > > > > factor fill ratio given 0, needed 0<br>
>> > > > > > Factored matrix follows:<br>
>> > > > > > Mat Object: 4 MPI processes<br>
>> > > > > > type: mpiaij<br>
>> > > > > > rows=938910, cols=938910<br>
>> > > > > > package used to perform factorization: pastix<br>
>> > > > > > total: nonzeros=0, allocated nonzeros=0<br>
>> > > > > > Error : 3.36878e-14<br>
>> > > > > > total number of mallocs used during MatSetValues calls<br>
>> =0<br>
>> > > > > > PaStiX run parameters:<br>
>> > > > > > Matrix type : Unsymmetric<br>
>> > > > > > Level of printing (0,1,2): 0<br>
>> > > > > > Number of refinements iterations : 3<br>
>> > > > > > Error : 3.36878e-14<br>
>> > > > > > linear system matrix = precond matrix:<br>
>> > > > > > Mat Object: (fieldsplit_u_) 4 MPI processes<br>
>> > > > > > type: mpiaij<br>
>> > > > > > rows=938910, cols=938910, bs=3<br>
>> > > > > > Error : 3.36878e-14<br>
>> > > > > > Error : 3.36878e-14<br>
>> > > > > > total: nonzeros=8.60906e+07, allocated<br>
>> nonzeros=8.60906e+07<br>
>> > > > > > total number of mallocs used during MatSetValues calls =0<br>
>> > > > > > using I-node (on process 0) routines: found 78749<br>
>> nodes, limit used is 5<br>
>> > > > > > Split number 1 Defined by IS<br>
>> > > > > > KSP Object: (fieldsplit_wp_) 4 MPI processes<br>
>> > > > > > type: richardson<br>
>> > > > > > Richardson: damping factor=1<br>
>> > > > > > maximum iterations=1, initial guess is zero<br>
>> > > > > > tolerances: relative=1e-05, absolute=1e-50,<br>
>> divergence=10000<br>
>> > > > > > left preconditioning<br>
>> > > > > > using PRECONDITIONED norm type for convergence test<br>
>> > > > > > PC Object: (fieldsplit_wp_) 4 MPI processes<br>
>> > > > > > type: lu<br>
>> > > > > > LU: out-of-place factorization<br>
>> > > > > > tolerance for zero pivot 2.22045e-14<br>
>> > > > > > matrix ordering: natural<br>
>> > > > > > factor fill ratio given 0, needed 0<br>
>> > > > > > Factored matrix follows:<br>
>> > > > > > Mat Object: 4 MPI processes<br>
>> > > > > > type: mpiaij<br>
>> > > > > > rows=34141, cols=34141<br>
>> > > > > > package used to perform factorization: pastix<br>
>> > > > > > Error : -nan<br>
>> > > > > > Error : -nan<br>
>> > > > > > Error : -nan<br>
>> > > > > > total: nonzeros=0, allocated nonzeros=0<br>
>> > > > > > total number of mallocs used during MatSetValues<br>
>> calls =0<br>
>> > > > > > PaStiX run parameters:<br>
>> > > > > > Matrix type : Symmetric<br>
>> > > > > > Level of printing (0,1,2): 0<br>
>> > > > > > Number of refinements iterations : 0<br>
>> > > > > > Error : -nan<br>
>> > > > > > linear system matrix = precond matrix:<br>
>> > > > > > Mat Object: (fieldsplit_wp_) 4 MPI processes<br>
>> > > > > > type: mpiaij<br>
>> > > > > > rows=34141, cols=34141<br>
>> > > > > > total: nonzeros=485655, allocated nonzeros=485655<br>
>> > > > > > total number of mallocs used during MatSetValues calls =0<br>
>> > > > > > not using I-node (on process 0) routines<br>
>> > > > > > linear system matrix = precond matrix:<br>
>> > > > > > Mat Object: 4 MPI processes<br>
>> > > > > > type: mpiaij<br>
>> > > > > > rows=973051, cols=973051<br>
>> > > > > > total: nonzeros=9.90037e+07, allocated nonzeros=9.90037e+07<br>
>> > > > > > total number of mallocs used during MatSetValues calls =0<br>
>> > > > > > using I-node (on process 0) routines: found 78749 nodes,<br>
>> limit used is 5<br>
>> > > > > ><br>
>> > > > > ><br>
>> > > > > ><br>
>> > > > > > Giang<br>
>> > > > > ><br>
>> > > > > > On Sun, Apr 23, 2017 at 10:19 PM, Barry Smith <<br>
>><span class="m_8426486426086775844m_2348089183134207201m_7797658317358904813Apple-converted-space"> </span><a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
>> > > > > ><br>
>> > > > > > > On Apr 23, 2017, at 2:42 PM, Hoang Giang Bui <<br>
>><span class="m_8426486426086775844m_2348089183134207201m_7797658317358904813Apple-converted-space"> </span><a href="mailto:hgbk2008@gmail.com" target="_blank">hgbk2008@gmail.com</a>> wrote:<br>
>> > > > > > ><br>
>> > > > > > > Dear Matt/Barry<br>
>> > > > > > ><br>
>> > > > > > > With your options, it results in<br>
>> > > > > > ><br>
>> > > > > > > 0 KSP preconditioned resid norm 1.106709687386e+31 true<br>
>> resid norm 9.015150491938e+06 ||r(i)||/||b|| 1.000000000000e+00<br>
>> > > > > > > Residual norms for fieldsplit_u_ solve.<br>
>> > > > > > > 0 KSP Residual norm 2.407308987203e+36<br>
>> > > > > > > 1 KSP Residual norm 5.797185652683e+72<br>
>> > > > > ><br>
>> > > > > > It looks like Matt is right, hypre is seemly producing useless<br>
>> garbage.<br>
>> > > > > ><br>
>> > > > > > First how do things run on one process. If you have similar<br>
>> problems then debug on one process (debugging any kind of problem is always<br>
>> far easy on one process).<br>
>> > > > > ><br>
>> > > > > > First run with -fieldsplit_u_type lu (instead of using hypre) to<br>
>> see if that works or also produces something bad.<br>
>> > > > > ><br>
>> > > > > > What is the operator and the boundary conditions for u? It could<br>
>> be singular.<br>
>> > > > > ><br>
>> > > > > ><br>
>> > > > > ><br>
>> > > > > ><br>
>> > > > > ><br>
>> > > > > ><br>
>> > > > > > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > > > > > 0 KSP Residual norm 0.000000000000e+00<br>
>> > > > > > > ...<br>
>> > > > > > > 999 KSP preconditioned resid norm 2.920157329174e+12 true<br>
>> resid norm 9.015683504616e+06 ||r(i)||/||b|| 1.000059124102e+00<br>
>> > > > > > > Residual norms for fieldsplit_u_ solve.<br>
>> > > > > > > 0 KSP Residual norm 1.533726746719e+36<br>
>> > > > > > > 1 KSP Residual norm 3.692757392261e+72<br>
>> > > > > > > Residual norms for fieldsplit_wp_ solve.<br>
>> > > > > > > 0 KSP Residual norm 0.000000000000e+00<br>
>> > > > > > ><br>
>> > > > > > > Do you suggest that the pastix solver for the "wp" block<br>
>> encounters small pivot? In addition, seem like the "u" block is also<br>
>> singular.<br>
>> > > > > > ><br>
>> > > > > > > Giang<br>
>> > > > > > ><br>
>> > > > > > > On Sun, Apr 23, 2017 at 7:39 PM, Barry Smith <<br>
>><span class="m_8426486426086775844m_2348089183134207201m_7797658317358904813Apple-converted-space"> </span><a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
>> > > > > > ><br>
>> > > > > > > Huge preconditioned norms but normal unpreconditioned norms<br>
>> almost always come from a very small pivot in an LU or ILU factorization.<br>
>> > > > > > ><br>
>> > > > > > > The first thing to do is monitor the two sub solves. Run<br>
>> with the additional options -fieldsplit_u_ksp_type richardson<br>
>> -fieldsplit_u_ksp_monitor -fieldsplit_u_ksp_max_it 1<br>
>> -fieldsplit_wp_ksp_type richardson -fieldsplit_wp_ksp_monitor<br>
>> -fieldsplit_wp_ksp_max_it 1<br>
>> > > > > > ><br>
>> > > > > > > > On Apr 23, 2017, at 12:22 PM, Hoang Giang Bui <<br>
>><span class="m_8426486426086775844m_2348089183134207201m_7797658317358904813Apple-converted-space"> </span><a href="mailto:hgbk2008@gmail.com" target="_blank">hgbk2008@gmail.com</a>> wrote:<br>
>> > > > > > > ><br>
>> > > > > > > > Hello<br>
>> > > > > > > ><br>
>> > > > > > > > I encountered a strange convergence behavior that I have<br>
>> trouble to understand<br>
>> > > > > > > ><br>
>> > > > > > > > KSPSetFromOptions completed<br>
>> > > > > > > > 0 KSP preconditioned resid norm 1.106709687386e+31 true<br>
>> resid norm 9.015150491938e+06 ||r(i)||/||b|| 1.000000000000e+00<br>
>> > > > > > > > 1 KSP preconditioned resid norm 2.933141742664e+29 true<br>
>> resid norm 9.015152282123e+06 ||r(i)||/||b|| 1.000000198575e+00<br>
>> > > > > > > > 2 KSP preconditioned resid norm 9.686409637174e+16 true<br>
>> resid norm 9.015354521944e+06 ||r(i)||/||b|| 1.000022631902e+00<br>
>> > > > > > > > 3 KSP preconditioned resid norm 4.219243615809e+15 true<br>
>> resid norm 9.017157702420e+06 ||r(i)||/||b|| 1.000222648583e+00<br>
>> > > > > > > > .....<br>
>> > > > > > > > 999 KSP preconditioned resid norm 3.043754298076e+12 true<br>
>> resid norm 9.015425041089e+06 ||r(i)||/||b|| 1.000030454195e+00<br>
>> > > > > > > > 1000 KSP preconditioned resid norm 3.043000287819e+12 true<br>
>> resid norm 9.015424313455e+06 ||r(i)||/||b|| 1.000030373483e+00<br>
>> > > > > > > > Linear solve did not converge due to DIVERGED_ITS iterations<br>
>> 1000<br>
>> > > > > > > > KSP Object: 4 MPI processes<br>
>> > > > > > > > type: gmres<br>
>> > > > > > > > GMRES: restart=1000, using Modified Gram-Schmidt<br>
>> Orthogonalization<br>
>> > > > > > > > GMRES: happy breakdown tolerance 1e-30<br>
>> > > > > > > > maximum iterations=1000, initial guess is zero<br>
>> > > > > > > > tolerances: relative=1e-20, absolute=1e-09,<br>
>> divergence=10000<br>
>> > > > > > > > left preconditioning<br>
>> > > > > > > > using PRECONDITIONED norm type for convergence test<br>
>> > > > > > > > PC Object: 4 MPI processes<br>
>> > > > > > > > type: fieldsplit<br>
>> > > > > > > > FieldSplit with MULTIPLICATIVE composition: total splits<br>
>> = 2<br>
>> > > > > > > > Solver info for each split is in the following KSP<br>
>> objects:<br>
>> > > > > > > > Split number 0 Defined by IS<br>
>> > > > > > > > KSP Object: (fieldsplit_u_) 4 MPI processes<br>
>> > > > > > > > type: preonly<br>
>> > > > > > > > maximum iterations=10000, initial guess is zero<br>
>> > > > > > > > tolerances: relative=1e-05, absolute=1e-50,<br>
>> divergence=10000<br>
>> > > > > > > > left preconditioning<br>
>> > > > > > > > using NONE norm type for convergence test<br>
>> > > > > > > > PC Object: (fieldsplit_u_) 4 MPI processes<br>
>> > > > > > > > type: hypre<br>
>> > > > > > > > HYPRE BoomerAMG preconditioning<br>
>> > > > > > > > HYPRE BoomerAMG: Cycle type V<br>
>> > > > > > > > HYPRE BoomerAMG: Maximum number of levels 25<br>
>> > > > > > > > HYPRE BoomerAMG: Maximum number of iterations PER<br>
>> hypre call 1<br>
>> > > > > > > > HYPRE BoomerAMG: Convergence tolerance PER hypre<br>
>> call 0<br>
>> > > > > > > > HYPRE BoomerAMG: Threshold for strong coupling 0.6<br>
>> > > > > > > > HYPRE BoomerAMG: Interpolation truncation factor 0<br>
>> > > > > > > > HYPRE BoomerAMG: Interpolation: max elements per row<br>
>> 0<br>
>> > > > > > > > HYPRE BoomerAMG: Number of levels of aggressive<br>
>> coarsening 0<br>
>> > > > > > > > HYPRE BoomerAMG: Number of paths for aggressive<br>
>> coarsening 1<br>
>> > > > > > > > HYPRE BoomerAMG: Maximum row sums 0.9<br>
>> > > > > > > > HYPRE BoomerAMG: Sweeps down 1<br>
>> > > > > > > > HYPRE BoomerAMG: Sweeps up 1<br>
>> > > > > > > > HYPRE BoomerAMG: Sweeps on coarse 1<br>
>> > > > > > > > HYPRE BoomerAMG: Relax down<br>
>> symmetric-SOR/Jacobi<br>
>> > > > > > > > HYPRE BoomerAMG: Relax up<br>
>> symmetric-SOR/Jacobi<br>
>> > > > > > > > HYPRE BoomerAMG: Relax on coarse<br>
>> Gaussian-elimination<br>
>> > > > > > > > HYPRE BoomerAMG: Relax weight (all) 1<br>
>> > > > > > > > HYPRE BoomerAMG: Outer relax weight (all) 1<br>
>> > > > > > > > HYPRE BoomerAMG: Using CF-relaxation<br>
>> > > > > > > > HYPRE BoomerAMG: Measure type local<br>
>> > > > > > > > HYPRE BoomerAMG: Coarsen type PMIS<br>
>> > > > > > > > HYPRE BoomerAMG: Interpolation type classical<br>
>> > > > > > > > linear system matrix = precond matrix:<br>
>> > > > > > > > Mat Object: (fieldsplit_u_) 4 MPI processes<br>
>> > > > > > > > type: mpiaij<br>
>> > > > > > > > rows=938910, cols=938910, bs=3<br>
>> > > > > > > > total: nonzeros=8.60906e+07, allocated<br>
>> nonzeros=8.60906e+07<br>
>> > > > > > > > total number of mallocs used during MatSetValues<br>
>> calls =0<br>
>> > > > > > > > using I-node (on process 0) routines: found 78749<br>
>> nodes, limit used is 5<br>
>> > > > > > > > Split number 1 Defined by IS<br>
>> > > > > > > > KSP Object: (fieldsplit_wp_) 4 MPI processes<br>
>> > > > > > > > type: preonly<br>
>> > > > > > > > maximum iterations=10000, initial guess is zero<br>
>> > > > > > > > tolerances: relative=1e-05, absolute=1e-50,<br>
>> divergence=10000<br>
>> > > > > > > > left preconditioning<br>
>> > > > > > > > using NONE norm type for convergence test<br>
>> > > > > > > > PC Object: (fieldsplit_wp_) 4 MPI processes<br>
>> > > > > > > > type: lu<br>
>> > > > > > > > LU: out-of-place factorization<br>
>> > > > > > > > tolerance for zero pivot 2.22045e-14<br>
>> > > > > > > > matrix ordering: natural<br>
>> > > > > > > > factor fill ratio given 0, needed 0<br>
>> > > > > > > > Factored matrix follows:<br>
>> > > > > > > > Mat Object: 4 MPI processes<br>
>> > > > > > > > type: mpiaij<br>
>> > > > > > > > rows=34141, cols=34141<br>
>> > > > > > > > package used to perform factorization: pastix<br>
>> > > > > > > > Error : -nan<br>
>> > > > > > > > Error : -nan<br>
>> > > > > > > > total: nonzeros=0, allocated nonzeros=0<br>
>> > > > > > > > Error : -nan<br>
>> > > > > > > > total number of mallocs used during MatSetValues calls =0<br>
>> > > > > > > > PaStiX run parameters:<br>
>> > > > > > > > Matrix type :<br>
>> Symmetric<br>
>> > > > > > > > Level of printing (0,1,2): 0<br>
>> > > > > > > > Number of refinements iterations : 0<br>
>> > > > > > > > Error : -nan<br>
>> > > > > > > > linear system matrix = precond matrix:<br>
>> > > > > > > > Mat Object: (fieldsplit_wp_) 4 MPI processes<br>
>> > > > > > > > type: mpiaij<br>
>> > > > > > > > rows=34141, cols=34141<br>
>> > > > > > > > total: nonzeros=485655, allocated nonzeros=485655<br>
>> > > > > > > > total number of mallocs used during MatSetValues<br>
>> calls =0<br>
>> > > > > > > > not using I-node (on process 0) routines<br>
>> > > > > > > > linear system matrix = precond matrix:<br>
>> > > > > > > > Mat Object: 4 MPI processes<br>
>> > > > > > > > type: mpiaij<br>
>> > > > > > > > rows=973051, cols=973051<br>
>> > > > > > > > total: nonzeros=9.90037e+07, allocated<br>
>> nonzeros=9.90037e+07<br>
>> > > > > > > > total number of mallocs used during MatSetValues calls =0<br>
>> > > > > > > > using I-node (on process 0) routines: found 78749<br>
>> nodes, limit used is 5<br>
>> > > > > > > ><br>
>> > > > > > > > The pattern of convergence gives a hint that this system is<br>
>> somehow bad/singular. But I don't know why the preconditioned error goes up<br>
>> too high. Anyone has an idea?<br>
>> > > > > > > ><br>
>> > > > > > > > Best regards<br>
>> > > > > > > > Giang Bui<br>
>> > > > > > > ><br>
>> > > > > > ><br>
>> > > > > > ><br>
>> > > > > ><br>
>> > > > > ><br>
>> > > > ><br>
>> > > > ><br>
>> > > ><br>
>> > > ><br>
>> > ><br>
>> > ><br>
>> ><br>
>> ><br>
>><br>
>><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
--<span class="m_8426486426086775844m_2348089183134207201m_7797658317358904813Apple-converted-space"> </span><br>
<div class="m_8426486426086775844m_2348089183134207201m_7797658317358904813gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener</div>
</div>
</div>
</div>
</blockquote>
</div></div></div>
<br>
</div>
</blockquote></div><br></div></div>