On Tue, 10 Mar 2009, Derek Gaston wrote:
> In particular there are some nice coloring algorithms in NOX that
> will give you HUGE speed boosts.
Compared to finite differencing the whole residual in one direction at
a time? Sure. It's exactly what I did on top of deal.II.
Compared to finite di
On Tue, 10 Mar 2009, Derek Gaston wrote:
> On Mar 10, 2009, at 12:47 PM, Roy Stogner wrote:
>
> Well... there are a couple of reasons. The main one is that ours is
> engineered for matrix free solves.
Can't be done with FEMSystem without changing the code - but it
wouldn't be a huge change.
>
On Mar 10, 2009, at 12:47 PM, Roy Stogner wrote:
> Yeah. How'd that happen again? ;-) You could have gotten some of
> your features for free (including those finite differenced Jacobians)
> just by building on top of FEMSystem, and the new features you've
> added seem to be things I'm going to
On Mar 10, 2009, at 12:47 PM, Roy Stogner wrote:
>> I'm in the same boat myself... having grown a similar but
>> completely incompatible non-linear solver framework in house
>
> Yeah. How'd that happen again? ;-) You could have gotten some of
> your features for free (including those fini
On Tue, 10 Mar 2009, Derek Gaston wrote:
> Doing a full transpose is what I would suggest. It will be less error prone
> and easier to debug. We can figure out later if we can take some shortcuts.
>
> In Epetra I believe you use an Epetra_RowMatrixTransposer to create a
> transpose. See here
On Mar 10, 2009, at 11:52 AM, Roy Stogner wrote:
> The only question left there is: what do we do for the linear algebra
> interface? PETSc's "KSPSolveTranspose" seems to be an internal
> routine that doesn't work with their real KSPs. Their
> MatCreateTranspose just creates a proxy matrix, and
On Tue, 10 Mar 2009, Derek Gaston wrote:
> On Mar 10, 2009, at 10:51 AM, Roy Stogner wrote:
>
>> For non-transient non-Jacobian-free systems, this would just do an
>> assembly, take the matrix transpose, assemble a new rhs with whatever
>> quantity of interest functional the user specifies (via a
On Mar 10, 2009, at 10:51 AM, Roy Stogner wrote:
>
> Derek, Dr. Carey tells me you told him that INL's planning to do some
> adjoint-based parameter sensitivity work with libMesh up there? We
> ought to coordinate; I'm getting ready to try out some hacks to do the
> exact same thing with libMesh/
Derek, Dr. Carey tells me you told him that INL's planning to do some
adjoint-based parameter sensitivity work with libMesh up there? We
ought to coordinate; I'm getting ready to try out some hacks to do the
exact same thing with libMesh/FINS.
My thoughts so far:
We ought to be able to put Syst
On Tue, 10 Mar 2009, Roy Stogner wrote:
> if I can't find the bug right away.
Found it. In UnstructuredMesh::contract() we loop over elements in no
particular order and delete the subactive ones, but in devel or debug
mode we test elem->level() to make sure it's not 0. elem->level() on
a non-l
On Tue, 10 Mar 2009, Tim Kroeger wrote:
> Talking about asserts, what do you think about the attached patch?
A very good idea - I'll commit it now.
> (I'm now using METHOD=devel and try to catch my crash using asserts, and I
> suspect now that it's in the ghosted part of PetscVector somewhere
On Mon, 9 Mar 2009, Roy Stogner wrote:
On Mon, 9 Mar 2009, Tim Kroeger wrote:
But wouldn't we be catching that with a libmesh_assert()? The
preconditions on operator= in petsc_vector.C seem pretty thorough.
But only in debug mode, right?
Right.
Talking about asserts, what do you think
12 matches
Mail list logo
