dolfin team mailing list archive

[Johan Hake <hake.dev@xxxxxxxxx>]

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 <martinal@xxxxxxxxx
> <mailto:martinal@xxxxxxxxx>> 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
> 
>