dolfin team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

I don't see the need for the special syntax in the Constant construction?

So, say we have:
  time = Constant(0.0)
  time_dep_expression1 = Expression("sin(t)", t=time)
  time_dep_expression2 = Expression("cos(t)", t=time)
Should this be legal then?
  time_dep_expression1.t = 0.2
  print time_dep_expression2.t # This would then print 0.2

Anyway, I think I like it. I want to introduce full ufl-to-Expression
compilation officially at some point as well (already available in uflacs).
Then it could just be
  time = Constant(0.0)
  time_dep_expression = Expression(sin(time))
and there would be no way to access 'time' through time_dep_expression.

Martin



On 15 February 2013 12:04, Johan Hake <hake.dev@xxxxxxxxx> wrote:

> 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
>
>