> On Tue, 28 Sep 2010, John Peterson wrote:
>> I have a local change fixing the setting of the time variable in the
>> In order to do that, I needed access to the "deltat" variable from the
>> System which created the FEMContext.
>> The approach I'm currently using requires the creating System be
>> derived from a FEMSystem, so that the existence of deltat is
>> guaranteed. We discussed moving deltat to System itself so that this
>> assumption is no longer required, but IIRC correctly you weren't
>> super-enthusiastic about that solution, since forcing a deltat
>> parameter on the base System class (which may represent a steady set
>> of equations) was less than desirable.
>> Should I go ahead and move deltat to System, or did you have something
>> else in mind? Alternatively we could wait until after the release,
>> but this does fix a potential bug in FEMContext so it might be good to
>> get out now.
> Damn, I'd forgotten about that one. I'd rather fix it now, certainly;
> otherwise we're killing higher-order time discretization accuracy for
> anyone whose FEMSystem physics depends directly on t and not just on
> Double damn. I just realized I was describing an undiagnosed problem
> that Paul Bauman saw; I'll Cc: this to him.
> But although a bad fix would be better than no fix, I'd still like to
> avoid an aesthetically bad fix, so let's try to brainstorm other
> options first.
> Perhaps give DiffContext a Real* _delta_t member variable, default
> NULL, with setter/getter options? build_context() in a DiffSystem
> would assign that to the system delta_t, users with their own
> transient systems could assign it instead to their own time step, and
> we'd just have to test for NULL before using it within DiffContext or
> a subclass.
> David, any thoughts? You and the other RB folks are probably the only
> ones currently using DiffContext in transient systems other than
Your Real* _delta_t idea would work fine in the RB context too, so I'd
be happy with that.