dolfin team mailing list archive

[Johan Hake <hake.dev@xxxxxxxxx>]

Thinking just a little more about this I should be able to do what I
want by enabling the following syntax in the CompiledExpression interface:

  time = Constant("t", t=0.0)
  time_dep_expression = Expression("sin(t)", t=time)

Here we need to check that time is a scalar Constant, if so we generate
a public Constant attribute instead of a double. The double operator in
the Constant interface would make the code work nicely. With some luck will:

  time_dep_expression.time = 0.2

still work from Python dependent on how that call propagates down into
C++ ;).

The time object can then be used to declare forms aso. Finally it can be
passed to the Solver which then take responsibility for updating it.

Anyone viscously against implementing the above feature in the
CompileExpression interface?

Johan

On 02/15/2013 11:39 AM, Garth N. Wells wrote:
> I'm all for improved time support, but agree with Martin that a global
> Time class is not the way to go.
> 
> Garth
> 
> On 15 February 2013 10:33, Johan Hake <hake.dev@xxxxxxxxx> 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
>>
>> 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
>>>
>>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dolfin
>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dolfin
>> More help   : https://help.launchpad.net/ListHelp