On Wed, Oct 22, 2008 at 11:52 AM, Jed Brown <[EMAIL PROTECTED]> wrote:
> trying to keep this on -devel...
Oops, yes I will try and do the same.
[snipped]
> The scary thing here would be the implicit cast (creating a new
> PetscMatrix which is a MatShell) occurs when a Matrix (which might even
>
Ok - I committed this patch... but something isn't quite sitting well
with me.
_map really should be valid all the time. I'm wondering if maybe
we're not setting it in a copy constructor or something...
If _map isn't valid then localize() isn't going to work properly...
and that would be v
On Wed, Oct 22, 2008 at 5:38 AM, Tim Kroeger
<[EMAIL PROTECTED]> wrote:
>
> On Tue, 21 Oct 2008, John Peterson wrote:
>
>> The attached updated class tree shows how I now
>> envision the hierarchy going.
>
> Your inheritance hierarchy makes user code that uses the shell matrices
> functionality sol
trying to keep this on -devel...
On Wed 2008-10-22 12:38, Tim Kroeger wrote:
> Your inheritance hierarchy makes user code that uses the shell matrices
> functionality solver dependent: The user has to explicitly instantiate
> e.g. PetscDyadMatrix. You might later implement shell matrices for ot
On Wed, 22 Oct 2008, Norbert Stoop wrote:
> I'm currently implementing an interface to NOX::LOCA (continuation
> methods in Trilinos) with the Epetra interface. This requires a header
> file (LOCA_Abstract_Iterator.H) which defines a stop() function
> conflicting with libmesh's own stop macro fro
Hi everyone!
I'm currently implementing an interface to NOX::LOCA (continuation
methods in Trilinos) with the Epetra interface. This requires a header
file (LOCA_Abstract_Iterator.H) which defines a stop() function
conflicting with libmesh's own stop macro from libmesh_common.h.
It seems the macro
