dolfin team mailing list archive

[Johan Hake <hake.dev@xxxxxxxxx>]

It would serve my need, but as Marting says what if a an Expression need
several time scales, aso.

If t here was a scalar Constant and passed to Expressions which needed
it, we would have more or less the same solution. However it would be
more flexible.

There might for example be other global variables which also should be
updated.

Johan

On 02/15/2013 11:51 AM, Anders Logg wrote:
> Can't we just make all Expression time-dependent by adding a variable
> 't' that all expressions have (set to 0 by default).
> 
> Then a user can either update t manually for all expressions, or
> connect them somehow to an object that handles time.
> 
> t = Time()
> t.add(e0)
> t.add(e1)
> t.add(e2)
> t.set(0.1) // Will set time for all managed expressions
> 
> --
> Anders
> 
> 
> On Fri, Feb 15, 2013 at 11:33:31AM +0100, Johan Hake wrote:
>> 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
> 
> 
> 
>>> 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
>>>
>>>    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     : dolfin@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dolfin
>> More help   : https://help.launchpad.net/ListHelp