On Tue, 29 Jun 2010, Roy Stogner wrote:
> Yeah; I'd have done that long ago if it wasn't for the backwards
> compatibility issue. For flexibility there's no better solution than
> Parameters, but for things we know we need we might as well avoid the
> string lookup.
Actually, for backwards comp
On Tue, 29 Jun 2010, Derek Gaston wrote:
> Actually... this would be a good reason to use Roy's suggestion of
> "fall-through" parameters it would allow you to _optionally_
> override the values at the System level. Of course that would mean
> changes to all of the solvers to look at the Sys
Actually... this would be a good reason to use Roy's suggestion of
"fall-through" parameters it would allow you to _optionally_ override the
values at the System level. Of course that would mean changes to all of the
solvers to look at the System level for parameters.
What we're really tal
On Tue, Jun 29, 2010 at 11:13 AM, Roy Stogner wrote:
>
> But seriously: it would be quite reasonable to add a Parameters object
> to each System as well, if you want. What I'd really like is a simple
> API for querying parameters that would check the System first, then
> check the EquationSystems
This is close to what I've done now.
If you guys think it would be useful to others I will add Parameters to
System... and can even do the "parent" parameters thing Roy was talking about.
Derek
On Jun 29, 2010, at 10:14 AM, John Peterson wrote:
> On Tue, Jun 29, 2010 at 11:05 AM, Derek Gaston
On Tue, Jun 29, 2010 at 11:05 AM, Derek Gaston wrote:
> Doh - are there not any Parameters on a System? I was planning on stuffing
> stuff into my NonlinearImplicitSystem so that I can get it back out when
> theNonlinearImplicitSystem get's passed into compute_residual / jacobian.
Your Systems h
On Tue, 29 Jun 2010, Derek Gaston wrote:
Doh - are there not any Parameters on a System? I was planning on
stuffing stuff into my NonlinearImplicitSystem so that I can get it
back out when the NonlinearImplicitSystem get's passed into
compute_residual / jacobian. Sigh.
No, the Parameters ob
Doh - are there not any Parameters on a System? I was planning on stuffing
stuff into my NonlinearImplicitSystem so that I can get it back out when the
NonlinearImplicitSystem get's passed into compute_residual / jacobian.
Sigh.
For now I can key off of it's name... does someone see a better way
Ok - I actually got around to doing this... and just committed the changes.
Who wants to send an official looking email about the change to the user
list?
Derek
On Fri, Apr 30, 2010 at 4:44 PM, Roy Stogner wrote:
>
>
> On Fri, 30 Apr 2010, Derek Gaston wrote:
>
> On Apr 30, 2010, at 1:59 PM, R
On Fri, 30 Apr 2010, Derek Gaston wrote:
> On Apr 30, 2010, at 1:59 PM, Roy Stogner wrote:
>
>> Basically not worth it to avoid a tiny API compatibility breakage.
Okay, Ben says 'yes'. Shoot us an email when you make the commit? In
hindsight, it'll take him 10 seconds to fix his code, and it'
On Apr 30, 2010, at 1:59 PM, Roy Stogner wrote:
> Ah, but that's what typecasts are for!
E!
> (joking!...)
You'd better be!
> I think the best you could do is overload the attachment methods, so
> that one takes the first kind of function pointer and the other takes
> the second, you store
On Apr 30, 2010, at 1:44 PM, Roy Stogner wrote:
> Okay, I misunderstood what we were talking about then. This is just
> fine - it effectively *is* what I was calling a "functor" approach,
> despite it not being a plain "overload operator()". I thought you
> were talking about requiring users to
On Fri, 30 Apr 2010, Derek Gaston wrote:
> I thought about this... but I don't think there is a way. I believe
> the signatures have to match exactly or the function pointer won't
> be accepted.
Ah, but that's what typecasts are for!
(joking!...)
> Could be wrong though...
I think the best y
I thought about this... but I don't think there is a way. I believe the
signatures have to match exactly or the function pointer won't be accepted.
Could be wrong though...
Derek
On Apr 30, 2010, at 1:36 PM, John Peterson wrote:
> On Fri, Apr 30, 2010 at 2:14 PM, Roy Stogner wrote:
>>
>> On
On Fri, 30 Apr 2010, Derek Gaston wrote:
On Apr 30, 2010, at 1:14 PM, Roy Stogner wrote:
I went a little *too* OO with FEMSystem - in hindsight there should
have been a separate subclassable Physics object to attach which
included the residual evaluation functions, and requir
On Apr 30, 2010, at 1:14 PM, Roy Stogner wrote:
> I went a little *too* OO with FEMSystem - in hindsight there should
> have been a separate subclassable Physics object to attach which
> included the residual evaluation functions, and requiring subclassing
> of FEMSystem itself was more work and
On Fri, Apr 30, 2010 at 2:14 PM, Roy Stogner wrote:
>
> On Fri, 30 Apr 2010, Derek Gaston wrote:
>
>> Objections?
>
> Yes - doing so with the existing functions would break backwards
> compatibility for other NonlinearSystem users; doing so by adding new
> functions would make the API redundant an
On Fri, 30 Apr 2010, Derek Gaston wrote:
> On Apr 30, 2010, at 12:29 PM, Roy Stogner wrote:
>
>> Personally I'd prefer turning residual/jacobian/matvec into functor
>> objects over adding a System* or void* state argument.
>
> Hmmm I think I prefer the object-oriented approach over this...
>
On Apr 30, 2010, at 12:29 PM, Roy Stogner wrote:
> Ah, I see. I guess Ben just assumed that nobody would be reusing the
> same residual function for multiple systems, but then
> dial-an-operator type frameworks break that assumption.
Exactly.
> Personally I'd prefer turning residual/jacobian/ma
On Fri, 30 Apr 2010, Derek Gaston wrote:
> On Apr 30, 2010, at 12:09 PM, Roy Stogner wrote:
>
>> We're currently passing back a pointer to the solver, ctx, and the
>> solver contains a pointer to the System, _system.
>
> Yes, this is what we get back from the callback from Petsc... I'm
> talking
On Apr 30, 2010, at 12:09 PM, Roy Stogner wrote:
> We're currently passing back a pointer to the solver, ctx, and the
> solver contains a pointer to the System, _system.
Yes, this is what we get back from the callback from Petsc... I'm talking about
the callback to user code. As in the function
On Fri, 30 Apr 2010, Derek Gaston wrote:
> 1. I change the signature of the residual and jacobian callbacks so
> that they pass a pointer to the System currently being solved for.
We're currently passing back a pointer to the solver, ctx, and the
solver contains a pointer to the System, _syste
22 matches
Mail list logo
