On Wed, 15 Sep 2010, Jed Brown wrote:
> On Wed, 15 Sep 2010 17:34:14 +0200 (CEST), Tim Kroeger
> wrote:
>
>> Assume further that the matrix is tridiagonal. If I then do what you
>> suggested, four matrix entries are lost (that is, (9,10), (10,9),
>> (19,20), (20,19)), aren't they? That's why I
On Wed, 15 Sep 2010 17:34:14 +0200 (CEST), Tim Kroeger
wrote:
> But now, let's assume
>
> all = [ 0 .. 9 | 10 .. 19 | 20 .. 29 ]
>
> and
>
> sub = [ 8 9 | 10 .. 19 | 20 21 22 ]
>
> Assume further that the matrix is tridiagonal. If I then do what you
> suggested, four matrix entries are lost
On Wed, 15 Sep 2010, Jed Brown wrote:
> On Wed, 15 Sep 2010 16:49:53 +0200 (CEST), Tim Kroeger
> wrote:
>
>>> VecScatter moves entries around, and isn't the issue here.
>>> Redistributing indices to satisfy some a-priori size bound is somewhat
>>> different (though not hard).
>>
>> So do I have
On Wed, 15 Sep 2010 09:50:25 -0500 (CDT), Roy Stogner
wrote:
> In the topological context I thought a domain had to be open and
> connected
It is always open in the subset topology, regarless of whether the
subset is open and/or closed in the parent space. No need for
connectedness either, x ->
On Wed, 15 Sep 2010 16:49:53 +0200 (CEST), Tim Kroeger
wrote:
> > VecScatter moves entries around, and isn't the issue here.
> > Redistributing indices to satisfy some a-priori size bound is somewhat
> > different (though not hard).
>
> So do I have to do something additional or not? I would th
On Wed, 15 Sep 2010, Roy Stogner wrote:
> On Wed, 15 Sep 2010, Jed Brown wrote:
>
>> On Wed, 15 Sep 2010 09:21:30 -0500 (CDT), Roy Stogner
>> wrote:
>>> but "domain" is sort of PDE specific whereas LinearSolver is not.
>>
>> FWIW, "domain" is topological (more general than linear or even metric
On Wed, 15 Sep 2010, Jed Brown wrote:
> On Wed, 15 Sep 2010 09:21:30 -0500 (CDT), Roy Stogner
> wrote:
>> but "domain" is sort of PDE specific whereas LinearSolver is not.
>
> FWIW, "domain" is topological (more general than linear or even metric
> spaces).
In the topological context I thought
On Wed, 15 Sep 2010, Jed Brown wrote:
> On Wed, 15 Sep 2010 14:53:18 +0200 (CEST), Tim Kroeger
> wrote:
>
>>> This chooses the sizes of each part, but you will still have to move
>>> indices around.
>>
>> This is done by VecScatter, isn't it? I think that the overhead of
>> doing this once befo
On Wed, 15 Sep 2010 09:21:30 -0500 (CDT), Roy Stogner
wrote:
> but "domain" is sort of PDE specific whereas LinearSolver is not.
FWIW, "domain" is topological (more general than linear or even metric
spaces).
Jed
--
St
On Wed, 15 Sep 2010, Tim Kroeger wrote:
> * (mainly to Roy:) Do you have some suggestion for a better name for
> solve_only_on()? (Jed suggested set_active_domain().)
What did I just suggest - restrict_to_subset()? I like "set_active_",
and "set_active_domain" would have been fine for the Sys
On Wed, 15 Sep 2010, Tim Kroeger wrote:
> Just to keep this clear: NumericVector::solve_only_on() will only accept a
> list of dofs, nothing else, because in particular a NumericVector does not
> know anything about subdomain ids.
Absolutely.
> On the other hand, System::solve_only_on() will
On Wed, 15 Sep 2010, Roy Stogner wrote:
> On Wed, 15 Sep 2010, Tim Kroeger wrote:
>
>> On Tue, 14 Sep 2010, Roy Stogner wrote:
>>
>>> Are you looking at just all elements which have a shape function
>>> associated with this DoF, or are you also including every element
>>> which supports an associ
On Wed, 15 Sep 2010 14:53:18 +0200 (CEST), Tim Kroeger
wrote:
> > This chooses the sizes of each part, but you will still have to move
> > indices around.
>
> This is done by VecScatter, isn't it? I think that the overhead of
> doing this once before and after the solve will be small against t
On Wed, 15 Sep 2010, Tim Kroeger wrote:
> On Tue, 14 Sep 2010, Roy Stogner wrote:
>
>> Are you looking at just all elements which have a shape function
>> associated with this DoF, or are you also including every element
>> which supports an associated basis function? In the former case it's
>>
On Wed, 15 Sep 2010, Jed Brown wrote:
On Wed, 15 Sep 2010 08:42:16 +0200 (CEST), Tim Kroeger
wrote:
(One conjecture why SAME_NONZERO_PATTERN has been used here before is
that somebody thought it means that the system matrix and the
preconditioner matrix have the same nonzero pattern, but as
On Wed, 15 Sep 2010 08:42:16 +0200 (CEST), Tim Kroeger
wrote:
> (One conjecture why SAME_NONZERO_PATTERN has been used here before is
> that somebody thought it means that the system matrix and the
> preconditioner matrix have the same nonzero pattern, but as far as I
> understand now, this is
On Wed, 15 Sep 2010, Jed Brown wrote:
> On Tue, 14 Sep 2010 09:00:39 +0200 (CEST), Tim Kroeger
> wrote:
>> Well, I could make it a vector instead, but then, on the other hand, I
>> guess that in most situations the user does not have any idea of which
>> order is best to use.
>
> That's what ord
On Tue, 14 Sep 2010 09:00:39 +0200 (CEST), Tim Kroeger
wrote:
> Well, I could make it a vector instead, but then, on the other hand, I
> guess that in most situations the user does not have any idea of which
> order is best to use.
That's what ordering packages are for, but defining the interf
18 matches
Mail list logo
