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....@gmail.com> 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....@gmail.com> 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 <marti...@simula.no
> >>> <mailto:marti...@simula.no>> 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@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~dolfin
> >> More help : https://help.launchpad.net/ListHelp
>
>
_______________________________________________
Mailing list: https://launchpad.net/~dolfin
Post to : dolfin@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dolfin
More help : https://help.launchpad.net/ListHelp
