On Thu, 9 Sep 2010, Jed Brown wrote:
> On Thu, 9 Sep 2010 16:14:39 +0200 (CEST), Tim Kroeger
> <[email protected]> wrote:
>>> Do you want to assemble X, or are you really only working with X2?
>>
>> Most probably, my assmble method will loop over X but skip every
>> element that is not contained in X2. This seems to be the easiest
>> assemble method at the moment.
>
> Okay, do you mind storing explicit zeros for all of X, even though you
> may not be touching them (or solving with them)? The alternative is to
> re-allocate when the sparsity pattern changes.
I don't mind storing all the zeros. The only condition is that
SuperLU_DIST does not get to see anything outside X2. I guess, your
recommendation is the right thing to do then.
>>> Maybe more interesting, you can provide the index sets to
>>> PCFieldSplit which gives you an additive or multiplicative method
>>> with a KSP created for each split (which you can control under the
>>> -fieldsplit_{0,1,...}_{ksp,pc}_ prefixes).
>>
>> I didn't understand this part at the moment.
>
> Suppose you have a system which after some permutations can be written
>
> [A B; C D]
>
> Then fieldsplit can give you solvers that solve these blocks together
> (like block-Jacobi, but partitioned by user-defined "fields") or
> multiplicatively (like a multiplicative Schwarz method, or block
> Gauss-Seidel with user-defined, and possibly overlapping splits), or
> Schur-complement methods. There is no restriction to 2x2. The solvers
> for all the pieces can be controlled at the command line (or through the
> API, but it's more work that way).
As far as I understand, this allows me to specify a partition of X2
into some subsets and then select solvers/preconditioners for these
subsets as well as a global method to combine them. However, I assume
that this will *not* move dofs to different processors, will it? So I
can't use this to improve the load balancing, can I?
I guess that this might be in particular a useful thing to do if X2
naturally consists of more than one connected component. This might
(in my application) in fact be the case, but not canonically, and
figuring this out might be complicated, and I also assume that
SuperLU_DIST anyway identifies the connected components, so that, for
the moment, I don't think I will need this.
Best Regards,
Tim
--
Dr. Tim Kroeger
CeVis -- Center of Complex Systems and Visualization
University of Bremen [email protected]
Universitaetsallee 29 [email protected]
D-28359 Bremen Phone +49-421-218-7710
Germany Fax +49-421-218-4236
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
