On Fri, 13 Mar 2009, Kirk, Benjamin (JSC-EG311) wrote:
>> The NonlinearSolver, in particular, has jacobian,
>> matvec, etc. as function pointers...
>
> i used function pointers as the method for interfacing with user code before
> I understood functors. Is it time to refactor the interfaces to u
> The NonlinearSolver, in particular, has jacobian,
> matvec, etc. as function pointers...
i used function pointers as the method for interfacing with user code before
I understood functors. Is it time to refactor the interfaces to use
function objects? I think we could provide a default functor
On Thu, 12 Mar 2009, Roy Stogner wrote:
> adjoint_solve() stubs (and QOI function attachment, etc) are in now.
And now adjoint_solve() implementations for non-transient problems are
in. I may or may not have time to futz with this again next week, so
Derek, if you or someone working with you is
On Tue, 10 Mar 2009, Derek Gaston wrote:
>> Sounds good. I'll commemorate the event by adding a stub
>> adjoint_solve() to SVN tonight. ;-)
You know, for loose definitions of "tonight".
> Sweet... that way I can claim it's "In Development"!
adjoint_solve() stubs (and QOI function attachment
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
13 matches
Mail list logo
