I see your points. Introducing a Time handler class which is
instantiated either by the user or by a solver might be the way to go.
This, however becomes more tricky to integrate with the
CompileExpression interface.
However, one could include some magic to the code generation process so:
time = Time()
e = Expression("t", t=time)
would generate an Expression with the shared time object attached to it,
preferable as private member. With this I think there is no need for an
explicit ExpressionWithTimeSupport class.
Also if t is a scalar it would generate an ordinary Expression with a
public double attribute.
Johan
On 02/15/2013 11:13 AM, Martin Sandve Alnæs wrote:
> Of course if such a class ExpressionWithTimeSupport is generic and
> useful enough and/or needed in official dolfin interfaces, the class can
> be added to dolfin.
>
> Martin
>
>
> On 15 February 2013 11:11, Martin Sandve Alnæs <[email protected]
> <mailto:[email protected]>> wrote:
>
> A single global time class is _not_ the way to go, that's not
> composable to multiphysics problems with different timescales, etc
> etc. It's a very narrow design for a very particular use case.
>
> However this is designed, it's a necessity that the user creates the
> "time object" (whatever that is) and passes it to whatever parts of
> the code that should share the same view of the time.
>
> The straightforward way to update time across Expression subclasses
> in C++ is to make the shared time a member of those classes.
>
> class MyExpr: Expression {
> MyExpr(shared_ptr<Time> t)> t(t) {}
> void eval(...) { double now = t->get_time(); ... }
> }
>
> This requires no library support. You can make a base class for
> Expressions with time support in your time solver code.
>
> Martin
>
>
_______________________________________________
Mailing list: https://launchpad.net/~dolfin
Post to : [email protected]
Unsubscribe : https://launchpad.net/~dolfin
More help : https://help.launchpad.net/ListHelp
