<div dir="ltr"><div>Thanks, I will definitely take a look.  </div><div> </div><div>Kan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 21, 2015 at 4:44 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  Since you have various "physics" in the same matrix you can use the PCFIELDSPLIT preconditioner to tack each of the physics separately and then combine them together within the same overall preconditioner. For example the pressure subproblem inside the large matrix should likely be solved with PCGAMG while the other parts not. Take a look at the manual page. Loosely speaking PCFIELDSPLIT is kind of like using an operator splitting only within the preconditioner.<br>
<span class="HOEnZb"><font color="#888888"><br>
   Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On Jan 21, 2015, at 4:21 PM, Chung-Kan Huang <<a href="mailto:ckhuangf@gmail.com">ckhuangf@gmail.com</a>> wrote:<br>
><br>
><br>
> On Wed, Jan 21, 2015 at 4:03 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> On Wed, Jan 21, 2015 at 3:16 PM, Chung-Kan Huang <<a href="mailto:ckhuangf@gmail.com">ckhuangf@gmail.com</a>> wrote:<br>
><br>
> On Wed, Jan 21, 2015 at 2:36 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> On Wed, Jan 21, 2015 at 2:29 PM, Chung-Kan Huang <<a href="mailto:ckhuangf@gmail.com">ckhuangf@gmail.com</a>> wrote:<br>
><br>
> On Wed, Jan 21, 2015 at 2:15 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> On Wed, Jan 21, 2015 at 2:07 PM, Chung-Kan Huang <<a href="mailto:ckhuangf@gmail.com">ckhuangf@gmail.com</a>> wrote:<br>
><br>
> On Wed, Jan 21, 2015 at 2:01 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> On Wed, Jan 21, 2015 at 1:55 PM, Chung-Kan Huang <<a href="mailto:ckhuangf@gmail.com">ckhuangf@gmail.com</a>> wrote:<br>
><br>
> On Wed, Jan 21, 2015 at 1:44 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> On Wed, Jan 21, 2015 at 1:40 PM, Chung-Kan Huang <<a href="mailto:ckhuangf@gmail.com">ckhuangf@gmail.com</a>> wrote:<br>
> Then A & AB are not longer the same matrix.  They become complete two individuals aren't they?<br>
> If I do whatever to AB after AB is created the A is still the same old A and not going to be affected by the operations I do to AB.<br>
><br>
> Yes.<br>
><br>
><br>
> What I am really looking for is a way to create two interfaces (one as AIJ and one as BAIJ) but they both refer to the same matrix.<br>
><br>
> Why would you ever want this? Why not just using BAIJ?<br>
> As I mentioned in the beginning.  There are parts of the code gets benifit when AIJ is used and the other part gets benifit  if BAIJ is used.<br>
><br>
> For instance,<br>
><br>
> I'd like to use MatSetValuesBlocked but I also want to use ilu constructed by AIJ instead of BAIJ (our experience found ilu from BAIJ behaves funny sometimes.<br>
><br>
> If the blocks truly are dense, then ILU(0) is identical on both.<br>
><br>
> Unfortunately the life is not that easy.  The blocks are spares and we found ILU(1) works better for our case.<br>
> And besides that is not the only reason I want to have AIJ & BAIJ interfaces, we have some code management issue and I am looking for short cut to unite them.<br>
><br>
> So go back to the original question the short answer is no way?<br>
><br>
> Yes, it would not make sense.<br>
><br>
> What problem are you using ILU(1) for?<br>
><br>
> I am using it for flow simulation for reservoir problems.<br>
><br>
> Have you considered trying algebraic multigrid?<br>
><br>
> I am solving PDE fully implicitly and as far as I know algebraic multigrid only good for pressure equations<br>
> I will need 2 stages PC while AMG is for pressure stage but I will still need something like ILU for second stage.<br>
><br>
> So you are using a mixed-formulation of Darcy? What equations do you have?<br>
> After some steps of reduction, the system equation solved in linear solver is basically the convervations of masses and energy.<br>
> Together I am solving the equations with natrual variables (pressure, temperature, saturations and molar fractions) .<br>
><br>
> It might have variable block size depend on local state and physics that considered.  For instant, I can skip mass transfer if it is impermeable to fluid locally but I still need to solve for conduction in energy balance equations.  I might also have some zones do not have some components so I can skip them as well.  Ideally I should have used variable size of block but I used the same size anyway in my previous BAIJ configuration as you pointed out some optimization can be done with the same size blocked matrix.<br>
><br>
> I switched to AIJ for reason related to ILU that I explained already. I didn't see the same problem in AIJ.<br>
><br>
> I am looking for room to improve linear solver performance in all aspects including CPU time to assemble the matrix and also good PC that are provided by PETSc.<br>
> Currently I am using AIJ + ILU(1) + overlay(1) +BCGS.  I am not so happy about scalbility but that is not in the scope of the problem I brought initially.  But I am interested if you have any good suggestions that I should test.<br>
><br>
> Thanks,<br>
><br>
> Kan<br>
><br>
>   Thanks,<br>
><br>
>      MAtt<br>
><br>
><br>
> Some issues we found is that<br>
> 1) for a * x = 0 it doesn't return x = 0<br>
><br>
> This is impossible. There must be a bug in the code.<br>
><br>
>   Thanks,<br>
><br>
>      Matt<br>
><br>
> 2) After compared ILU(1) with BAIJ against with ILU(1) with AIJ I found latter one is better.  I could not find anything wrong with my BAIJ version though.  However, experiences suggested that BAIJ's ILU(1) should be better.<br>
><br>
><br>
> Thanks,<br>
><br>
> Kan<br>
><br>
>   Thanks,<br>
><br>
>      Matt<br>
><br>
> Thanks,<br>
><br>
> Kan<br>
><br>
>   Matt<br>
><br>
> Thanks,<br>
><br>
> Kan<br>
><br>
>   Thanks,<br>
><br>
>       Matt<br>
><br>
> Thanks,<br>
><br>
> Kan<br>
> On Wed, Jan 21, 2015 at 1:20 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> On Wed, Jan 21, 2015 at 12:56 PM, Chung-Kan Huang <<a href="mailto:ckhuangf@gmail.com">ckhuangf@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> So if I do<br>
><br>
> Mat A, AB;<br>
> MatCreateAIJ(comm,m,n,M,N,d_nz, d_nnz,o_nz, o_nnz, &A);<br>
> MatConvert(A, MATBAIJ, MAT_INITAL_MATRIX, &AB);<br>
> MatSetBlockSize(AB, bs)<br>
> I can create AB as a BAIJ with block size of bs from A which is a AIJ matrix.<br>
><br>
> So from this point I can use both A and AB and they will mean the same matrix. Am I right?<br>
><br>
> Yes<br>
><br>
> At the end of the program do I only destory one of them or both?<br>
><br>
> Both<br>
><br>
> Do I need to worry about anything in terms of memory penalty?<br>
><br>
> It is twice the memory. Its another matrix.<br>
><br>
> Did you catch when Jed said you could jsut create the BAIJ up front?<br>
><br>
>   Thanks,<br>
><br>
>     Matt<br>
><br>
><br>
> Thanks,<br>
><br>
> Kan<br>
><br>
><br>
> On Tue, Jan 20, 2015 at 4:39 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
>   You can do a MatConvert() (requires another copy of the matrix) for the parts that benefit from BAIJ.<br>
><br>
>   Barry<br>
><br>
> > On Jan 20, 2015, at 4:33 PM, Chung-Kan Huang <<a href="mailto:ckhuangf@gmail.com">ckhuangf@gmail.com</a>> wrote:<br>
> ><br>
> > Hi,<br>
> ><br>
> > Does PETSc provide means for conversion between AIJ & BAIJ.<br>
> ><br>
> > My matrix is created as AIJ because it makes life easy for most part of the applications but some part of applications actually get some benefits with BAIJ.  So I wonder if a matrix can exist as two idenfities and I can use either format depend on which one is more convenient at run time.<br>
> ><br>
> > So in my case the block size is fixed and identical for all blocks.<br>
> ><br>
> ><br>
> > Thanks,<br>
> ><br>
> ><br>
> > Kan<br>
><br>
><br>
><br>
><br>
> --<br>
> Cheers<br>
><br>
><br>
><br>
><br>
> --<br>
> 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<br>
><br>
><br>
><br>
> --<br>
> Cheers<br>
><br>
><br>
><br>
><br>
> --<br>
> 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<br>
><br>
><br>
><br>
> --<br>
> Cheers<br>
><br>
><br>
><br>
><br>
> --<br>
> 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<br>
><br>
><br>
><br>
> --<br>
> Cheers<br>
><br>
><br>
><br>
><br>
> --<br>
> 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<br>
><br>
><br>
><br>
> --<br>
> Cheers<br>
><br>
><br>
><br>
><br>
> --<br>
> 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<br>
><br>
><br>
><br>
> --<br>
> Cheers<br>
><br>
><br>
><br>
><br>
> --<br>
> 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<br>
><br>
><br>
><br>
> --<br>
> Cheers<br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><p><strong>Cheers</strong></p></div>
</div>