On Wed, 1 Dec 2010, Roy Stogner wrote:
> On Tue, 23 Nov 2010, Tim Kroeger wrote:
>
>> t...@tkroeger-pc:~$ doxygen --version
>> 1.6.1
>>
>> Although not quite up-to-date, it isn't ancient either. Which version are
>> you using?
>
> 1.7.1 at the moment, but I think I've used 1.5.something earlie
On Tue, 23 Nov 2010, Tim Kroeger wrote:
> t...@tkroeger-pc:~$ doxygen --version
> 1.6.1
>
> Although not quite up-to-date, it isn't ancient either. Which version are
> you using?
1.7.1 at the moment, but I think I've used 1.5.something earlier with
no problems.
But I guess the important prog
On Mon, 22 Nov 2010, Roy Stogner wrote:
> On Mon, 22 Nov 2010, Tim Kroeger wrote:
>
>> Checked in everything now. I also updated the class docs, but there seems
>> to be something strange with this. That is, the inherticance diagrams now
>> look different than they did before. Did I do someth
On Mon, 22 Nov 2010, Tim Kroeger wrote:
> Checked in everything now. I also updated the class docs, but there seems to
> be something strange with this. That is, the inherticance diagrams now look
> different than they did before. Did I do something wrong? I did
>
> make doc
> L
On Thu, 18 Nov 2010, Tim Kroeger wrote:
> The subset-solve stuff now seems to work properly. At least, my application
> does not crash, and the output looks reasonable. I'd like to check-in this
> now, see attached patch, together with the example that I posted last week.
> If somebody has ob
On Tue, 9 Nov 2010, Tim Kroeger wrote:
> On Mon, 8 Nov 2010, Roy Stogner wrote:
>
>> I dislike ideas #1-3; no opinion on #4 vs #5, but want to add:
>>
>> Idea #6: Add an example 24 (or 25, whatever's free when this is all
>> finally finished) demonstrating a use of SystemSubset stuff.
>
> Good
On Mon, 8 Nov 2010, Roy Stogner wrote:
I dislike ideas #1-3; no opinion on #4 vs #5, but want to add:
Idea #6: Add an example 24 (or 25, whatever's free when this is all
finally finished) demonstrating a use of SystemSubset stuff.
Good point. I created an example now, see attachment. I will
On Mon, 8 Nov 2010, Tim Kroeger wrote:
> Idea #4: Upon removing the columns of the matrix, automatically adjust
> the right hand side. I think this would actually be quite easy to do
> by the following procedure:
>
> 1. Remove the inactive rows of the matrix.
>
> 2. Let B denote the
On Mon, 8 Nov 2010, Tim Kroeger wrote:
> Idea #4: Upon removing the columns of the matrix, automatically adjust
> the right hand side. I think this would actually be quite easy to do
> by the following procedure:
>
> 1. Remove the inactive rows of the matrix.
>
> 2. Let B denote the a
On Mon, 8 Nov 2010, Derek Gaston wrote:
> I haven't followed this whole thread so forgive me if this has been
> explained... but how do you end up with a refined element (D) being
> in a different subdomain from it's parent (that made up ABCD)? Is
> your subdomain evolving throughout the simul
On Nov 8, 2010, at 8:07 AM, Tim Kroeger wrote:
> The next difficulty with my solve-on-part-of-domain stuff has now
> shown up. It is the constrained-dof issue now, which Roy already
> predicted and I didn't believe. Luckily enough, my application seems
> to be sufficiently complicated for any
The next difficulty with my solve-on-part-of-domain stuff has now
shown up. It is the constrained-dof issue now, which Roy already
predicted and I didn't believe. Luckily enough, my application seems
to be sufficiently complicated for any potential problem to actually
occur.
Let's assume the
On Thu, 4 Nov 2010, Roy Stogner wrote:
>
> On Thu, 4 Nov 2010, Tim Kroeger wrote:
>
>> On Thu, 4 Nov 2010, Kirk, Benjamin (JSC-EG311) wrote:
>>
>>> I'm all for (1).
>>>
>>> Note thought that MPI_Request_free does not cancel communication -
>>> MPI_Cancel does. MPI_Request_free says you have no
On Thu, 4 Nov 2010, Tim Kroeger wrote:
> On Thu, 4 Nov 2010, Kirk, Benjamin (JSC-EG311) wrote:
>
>> I'm all for (1).
>>
>> Note thought that MPI_Request_free does not cancel communication -
>> MPI_Cancel does. MPI_Request_free says you have no need for this
>> particular
>> request - possibly
On Thu, 4 Nov 2010, Kirk, Benjamin (JSC-EG311) wrote:
> Tim - what compiler and MPI are you using? I'd like to make sure I can
> repeat this before declaring we know how to fix it.
The cluster is alive again. I'm using:
g++ (GCC) 4.1.2
mpich2-1.2
--
Dr. Tim Kroeger
CeVis -- Center of Comple
On Thu, 4 Nov 2010, Kirk, Benjamin (JSC-EG311) wrote:
I'm all for (1).
Note thought that MPI_Request_free does not cancel communication -
MPI_Cancel does. MPI_Request_free says you have no need for this particular
request - possibly because you will be able to infer when it has completed
due t
>> My only concern with #2 is the implicit shared reference behavior
>> between Request objects and MPI_Request objects. I could imagine
>> someone using a raw MPI_Request to initiate an operation, creating a
>> Request from it, letting the Request go out of scope (freeing the
>> underlying reques
On Thu, Nov 4, 2010 at 8:52 AM, Roy Stogner wrote:
>
> On Thu, 4 Nov 2010, Kirk, Benjamin (JSC-EG311) wrote:
>
Long-term, there are two policy options that I think make sense:
1. Don't ever do MPI_Request_free implicitly from a Request object.
2. Do reference counting in R
On Thu, 4 Nov 2010, Roy Stogner wrote:
> Could we add a libmesh_assert to the destructor, to make sure the
> request has been set to MPI_REQUEST_NULL (which I believe both the
> wait and free commands do)?
No, we can't. (-:
Because the current usage (that started this discussion) would be
ca
On Thu, 4 Nov 2010, Kirk, Benjamin (JSC-EG311) wrote:
Long-term, there are two policy options that I think make sense:
1. Don't ever do MPI_Request_free implicitly from a Request object.
2. Do reference counting in Request objects; do an MPI_Request_free
when the last
On Thu, 4 Nov 2010, Kirk, Benjamin (JSC-EG311) wrote:
> What are the downsides of 1.)?
I'd also like to know this one. It looks as if the only downside is a
memory leak in the case where a user accidentally ignores a Request
rather than waiting for it to complete? And in that case we can just
On Thu, 4 Nov 2010, Kirk, Benjamin (JSC-EG311) wrote:
>>> Long-term, there are two policy options that I think make sense:
>>>
>>> 1. Don't ever do MPI_Request_free implicitly from a Request object.
>>>
>>> 2. Do reference counting in Request objects; do an MPI_Request_free
>>> when the last refe
>>> Long-term, there are two policy options that I think make sense:
>>>
>>> 1. Don't ever do MPI_Request_free implicitly from a Request object.
>>>
>>> 2. Do reference counting in Request objects; do an MPI_Request_free
>>> when the last reference is destroyed.
>>>
>>> I can see pros and cons t
>> Long-term, there are two policy options that I think make sense:
>>
>> 1. Don't ever do MPI_Request_free implicitly from a Request object.
>>
>> 2. Do reference counting in Request objects; do an MPI_Request_free
>> when the last reference is destroyed.
>>
>> I can see pros and cons to each;
On Wed, 3 Nov 2010, Roy Stogner wrote:
> Long-term, there are two policy options that I think make sense:
>
> 1. Don't ever do MPI_Request_free implicitly from a Request object.
>
> 2. Do reference counting in Request objects; do an MPI_Request_free
> when the last reference is destroyed.
>
> I ca
Apologies for the late reply; I've been sick this week, and although
I'm mostly better my head's still not 100% back in the game.
My slightly-untrustworthy thoughts:
Yes, this is definitely a serious urgent issue. It's the kind of bug
that can avoid being triggered by some STL/MPI implementati
On Wed, Nov 3, 2010 at 12:32 PM, Kirk, Benjamin (JSC-EG311)
wrote:
>> wrote:
>>> On Fri, 22 Oct 2010, John Peterson wrote:
>>>
>>> Also, in the code that you mentioned, another thing happens which I think is
>>> dangerous: That is, you are having a
>>>
>>> std::vector node_send_requests;
>
> wrote:
>> On Fri, 22 Oct 2010, John Peterson wrote:
>>
>> Also, in the code that you mentioned, another thing happens which I think is
>> dangerous: That is, you are having a
>>
>> std::vector node_send_requests;
>>
>> (and a number of similar vectors), and then, each time you want to
On Wed, Nov 3, 2010 at 10:48 AM, Tim Kroeger
wrote:
> On Fri, 22 Oct 2010, John Peterson wrote:
>
> Also, in the code that you mentioned, another thing happens which I think is
> dangerous: That is, you are having a
>
> std::vector node_send_requests;
>
> (and a number of similar vectors),
On Fri, 22 Oct 2010, John Peterson wrote:
On Fri, Oct 22, 2010 at 2:46 AM, Tim Kroeger
wrote:
On Thu, 21 Oct 2010, Roy Stogner wrote:
It looks like there's a deadlock in here in parallel? You're doing
blocking sends followed by blocking receives? Probably need to switch
those (at least the
On Fri, Oct 22, 2010 at 2:46 AM, Tim Kroeger
wrote:
> On Thu, 21 Oct 2010, Roy Stogner wrote:
>
>> It looks like there's a deadlock in here in parallel? You're doing
>> blocking sends followed by blocking receives? Probably need to switch
>> those (at least the sends, but optimally both) to non-
On Fri, 22 Oct 2010, Roy Stogner wrote:
> On Fri, 22 Oct 2010, Tim Kroeger wrote:
>
>> On Thu, 21 Oct 2010, Roy Stogner wrote:
>>
>>> Would it make sense to loop over all active elements, not just local
>>> ones?
>>
>> That would certainly solve the problem, but it wouldn't scale well, would
>>
On Fri, 22 Oct 2010, Tim Kroeger wrote:
> On Thu, 21 Oct 2010, Roy Stogner wrote:
>
>> Would it make sense to loop over all active elements, not just local
>> ones?
>
> That would certainly solve the problem, but it wouldn't scale well, would it?
> (At least as long as ParallelMesh is not stabl
On Thu, 21 Oct 2010, Roy Stogner wrote:
It looks like there's a deadlock in here in parallel? You're doing
blocking sends followed by blocking receives? Probably need to switch
those (at least the sends, but optimally both) to non-blocking.
Good point. It worked for me, but aparently I've j
On Thu, 21 Oct 2010, Tim Kroeger wrote:
> On Wed, 20 Oct 2010, Tim Kroeger wrote:
>
>> My question now: Is there already a mechanism for solving this problem
>> nicely somewhere in the library? I guess it is (I remember that you
>> guys were talking about a "send_list"), but I don't know where
Sorry about the delay; I'm still digging through a big work backlog.
On Wed, 20 Oct 2010, Tim Kroeger wrote:
> I just tracked down a bug in my solve-on-part-of-domain stuff, that is in the
> (new) class SystemSubsetBySubdomain. The idea of this class is to create a
> list of all dofs that are
On Wed, 20 Oct 2010, Tim Kroeger wrote:
My question now: Is there already a mechanism for solving this problem
nicely somewhere in the library? I guess it is (I remember that you
guys were talking about a "send_list"), but I don't know where and how
to use it. If there is not, I will be able t
Dear all,
I just tracked down a bug in my solve-on-part-of-domain stuff, that is
in the (new) class SystemSubsetBySubdomain. The idea of this class is
to create a list of all dofs that are adjacent to at least one
(active) element whose subdomain id is contained is a given list.
The way it cu
On Tue, 21 Sep 2010, Roy Stogner wrote:
> Call this Possibility #7:
>
> int SystemSubset::set_revision gets incremented every time the dof
> list changes. LinearImplicitSystem::last_set_revision stores the
> set_revision that was used to create the current preconditioner.
> Before solving, we che
Ok. I've been somewhat following this... and here's my input.
I like option #1. I truly believe that this is an edge case... if you are
doing this much advanced stuff then you can worry about clearing your
preconditioner first. I don't like the idea that ANY user providing a custom
precondit
Cc:ing this to Derek to make sure he doesn't miss this one; I think
he's done the most libMesh work with custom preconditioners most
recently and he might have thoughts or see concerns we're missing.
My own thoughts:
On Tue, 21 Sep 2010, Tim Kroeger wrote:
> One problem just popped up with the
One problem just popped up with the subset stuff: PetscLinearSolver
keeps the _pc object constant across solves (... perhaps that was the
reason for using SAME_NONZERO_PATTERN?) unless
PetscLinearSolver::clear() is called in between. When the subset on
which to solve is changed, however, this
On Fri, 17 Sep 2010, Roy Stogner wrote:
> On Fri, 17 Sep 2010, Tim Kroeger wrote:
>
>> Thank you for this hint. Using this, it was easy to find the point where
>> the macro is not called. It's in libMesh, however, that is in
>> petsc_preconditioner.C, line 49. Actually, in that file, a lot of
On Fri, Sep 17, 2010 at 9:00 AM, Roy Stogner wrote:
> Derek's lazy? ;-)
>
LOL - That usually is the case... but in this case I think it was just lack
of diligence. I don't remember thinking "meh I'll just leave those out"...
I actually just didn't think of them at all ;-)
Me being lazy is alwa
On Fri, 17 Sep 2010, Tim Kroeger wrote:
> Thank you for this hint. Using this, it was easy to find the point where the
> macro is not called. It's in libMesh, however, that is in
> petsc_preconditioner.C, line 49. Actually, in that file, a lot of calls to
> CHKERRABORT() are missing. Roy,
On Fri, 17 Sep 2010, Jed Brown wrote:
> On Fri, Sep 17, 2010 at 16:35, Tim Kroeger
> wrote:
>> Can you (Jed) comment on how it can happen that KSPSolve() prints this error
>> message but nicely returns 0?
>
> CHKERRQ is not being called somewhere in the stack, if it's in PETSc
> code, please let
On Fri, Sep 17, 2010 at 16:35, Tim Kroeger
wrote:
> Can you (Jed) comment on how it can happen that KSPSolve() prints this error
> message but nicely returns 0?
CHKERRQ is not being called somewhere in the stack, if it's in PETSc
code, please let me know where it is (or send a full trace).
As a
I'm currently testing my application with the new subset stuff, and
I'm observing some PETSc behaviour that I find strange. At some place
in petsc_linear_solver.C, I do:
ierr = KSPSolve (_ksp, subrhs, subsolution);
CHKERRABORT(libMesh::COMM_WORLD,ierr);
What now happens is that
On Thu, 16 Sep 2010, Jed Brown wrote:
> Correct about shell and MFFD matrices. If the Mat does not implement
> MatGetSubMatrix then this call returns a matrix
> of type MatSubMatrix which works like you say (>=3.1).
Great, thank you. I will update to 3.1 now (was using 3.0.0-p8
before).
Best
Correct about shell and MFFD matrices. If the Mat does not implement
MatGetSubMatrix then this call returns a matrix of type MatSubMatrix which
works like you say (>=3.1). Preconditioning that thing obviously does not
come automatically.
Jed
On Sep 16, 2010 8:41 AM, "Tim Kroeger"
wrote:
On Wed,
Here is the current state now. I have no more questions (other than
the one which I asked in the previous mail). If Jed says that
everything looks well now, I will do the thing for the missing
overloaded PetscLinearSolver::solve() methods.
--
Dr. Tim Kroeger
CeVis -- Center of Complex System
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 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, 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
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. On the
> other hand, System::solve_only_on() will only accept (a r
On Tue, 14 Sep 2010, Roy Stogner wrote:
> On Tue, 14 Sep 2010, Tim Kroeger wrote:
>
>> I suggest to make two methods, one of which takes a vector and the other
>> takes a set. Then, the set-taking method will by default just convert the
>> set to a vector and call the vector-taking method. Roy
On Tue, 14 Sep 2010, Tim Kroeger wrote:
> I suggest to make two methods, one of which takes a vector and the other
> takes a set. Then, the set-taking method will by default just convert the
> set to a vector and call the vector-taking method. Roy, what do you think?
I think this is one of t
Dear Jed,
Thank you for your help so far. I still have some questions:
On Mon, 13 Sep 2010, Jed Brown wrote:
> On Mon, 13 Sep 2010 15:18:30 +0200 (CEST), Tim Kroeger
> wrote:
>
>> +
>> + /**
>> + * Set of dofs to which any solve is limited (\p NULL means solve on
>> + * all dofs).
>> +
comments inline
On Mon, 13 Sep 2010 15:18:30 +0200 (CEST), Tim Kroeger
wrote:
> Index: include/solvers/petsc_linear_solver.h
> ===
> --- include/solvers/petsc_linear_solver.h (Revision 3957)
> +++ include/solvers/petsc_linear_so
On Mon, 13 Sep 2010, Jed Brown wrote:
On Mon, 13 Sep 2010 11:35:17 +0200 (CEST), Tim Kroeger
wrote:
On Thu, 9 Sep 2010, Jed Brown wrote:
Do you want to assemble X, or are you really only working with X2? If
the former, you can MatGetSubMatrix (you just need an index set defining
the subdom
On Mon, 13 Sep 2010 11:35:17 +0200 (CEST), Tim Kroeger
wrote:
> On Thu, 9 Sep 2010, Jed Brown wrote:
>
> > Do you want to assemble X, or are you really only working with X2? If
> > the former, you can MatGetSubMatrix (you just need an index set defining
> > the subdomain) the part you want and
On Thu, 9 Sep 2010, Jed Brown wrote:
> Do you want to assemble X, or are you really only working with X2? If
> the former, you can MatGetSubMatrix (you just need an index set defining
> the subdomain) the part you want and solve with that.
What will I have to do with the right hand side and the
On Fri, 10 Sep 2010, Tim Kroeger wrote:
> Ah, perhaps you mean, that there should be *two* versions of
> System::solve_only_on(), one taking a std::set of dof ids, and the
> other like this:
>
> System::solve_only_on(const std::vector*const);
>
> where using "vector" rather than "set" avoids prob
On Thu, 9 Sep 2010, John Peterson wrote:
> On Thu, Sep 9, 2010 at 10:27 AM, Tim Kroeger
> wrote:
>
>> LinearSolver::solve_only_on(const std::set*const)
>
> Are you sure you don't want to add one more overloaded solve() member
> to LinearSolver? ;-)
Good idea, and also I would suggest to rename
On Thu, 9 Sep 2010, Roy Stogner wrote:
> On Thu, 9 Sep 2010, Tim Kroeger wrote:
>
>> My suggestion for an API in libMesh is as follows:
>>
>> LinearSolver gets a method
>>
>> LinearSolver::solve_only_on(const std::set*const)
>>
>> Likewise, System gets a method
>>
>> System::solve_only_on(cons
On Thu, Sep 9, 2010 at 10:27 AM, Tim Kroeger
wrote:
> My suggestion for an API in libMesh is as follows:
>
> LinearSolver gets a method
>
> LinearSolver::solve_only_on(const std::set*const)
> Likewise, System gets a method
>
> System::solve_only_on(const std::set*const)
Are you sure you don't wa
On Thu, 9 Sep 2010 10:41:29 -0500 (CDT), Roy Stogner
wrote:
>
> On Thu, 9 Sep 2010, Tim Kroeger wrote:
>
> > System::solve_only_on(const std::set*const)
You might want this to contain a communicator (i.e. be equivalent to a
PETSc IS) and an ordering (as Roy says) so that the same API can provi
On Thu, 9 Sep 2010, Tim Kroeger wrote:
> My suggestion for an API in libMesh is as follows:
>
> LinearSolver gets a method
>
> LinearSolver::solve_only_on(const std::set*const)
>
> after a call to which each call to LinearSolver::solve() will remove
> all dofs not contained in the list from the m
On Thu, 9 Sep 2010, Tim Kroeger wrote:
> On Thu, 9 Sep 2010, Jed Brown wrote:
>
>> On Thu, 9 Sep 2010 15:27:42 +0200 (CEST), Tim Kroeger
>> wrote:
>>> Dear all,
>>>
>>> Let X be a computational domain, covered by a Mesh on which an
>>> EquationSystems object is based on. Let X2 be a subset of X
On Thu, 9 Sep 2010 16:47:38 +0200 (CEST), Tim Kroeger
wrote:
> 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 *no
On Thu, 9 Sep 2010, David Knezevic wrote:
> On 09/09/2010 10:06 AM, Tim Kroeger wrote:
>>
>> On Thu, 9 Sep 2010, David Knezevic wrote:
>>
>>> You can specify variables that are defined only on X2 by specifying the
>>> appropriate subdomain id(s) when you add the variable to the system. See
>>> add
On Thu, 9 Sep 2010, Jed Brown wrote:
> On Thu, 9 Sep 2010 16:14:39 +0200 (CEST), Tim Kroeger
> 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
On Thu, 9 Sep 2010 16:14:39 +0200 (CEST), Tim Kroeger
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
On 09/09/2010 10:06 AM, Tim Kroeger wrote:
> Dear David,
>
> On Thu, 9 Sep 2010, David Knezevic wrote:
>
>> You can specify variables that are defined only on X2 by specifying the
>> appropriate subdomain id(s) when you add the variable to the system. See
>> add_variable in system.h
>
> Thank you f
Dear Jed,
On Thu, 9 Sep 2010, Jed Brown wrote:
> On Thu, 9 Sep 2010 15:27:42 +0200 (CEST), Tim Kroeger
> wrote:
>> Dear all,
>>
>> Let X be a computational domain, covered by a Mesh on which an
>> EquationSystems object is based on. Let X2 be a subset of X, given by
>> the union of selected gr
Dear David,
On Thu, 9 Sep 2010, David Knezevic wrote:
> You can specify variables that are defined only on X2 by specifying the
> appropriate subdomain id(s) when you add the variable to the system. See
> add_variable in system.h
Thank you for your reply. How does this solution behave if the
s
On Thu, 9 Sep 2010 15:27:42 +0200 (CEST), Tim Kroeger
wrote:
> Dear all,
>
> Let X be a computational domain, covered by a Mesh on which an
> EquationSystems object is based on. Let X2 be a subset of X, given by
> the union of selected grid elements (which are, say, marked by certain
> value
Hi Tim,
You can specify variables that are defined only on X2 by specifying the
appropriate subdomain id(s) when you add the variable to the system. See
add_variable in system.h
David
On 09/09/2010 09:27 AM, Tim Kroeger wrote:
> Dear all,
>
> Let X be a computational domain, covered by a Mes
Dear all,
Let X be a computational domain, covered by a Mesh on which an
EquationSystems object is based on. Let X2 be a subset of X, given by
the union of selected grid elements (which are, say, marked by certain
values of subdomain_id).
Assume I want (at some point in my application) to sol
92 matches
Mail list logo
