dolfin team mailing list archive

[Johan Hake <hake.dev@xxxxxxxxx>]

On 02/15/2013 12:54 PM, Martin Sandve Alnæs wrote:
> 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

That would be nice, but swig does not allow it. It expects a Constant.
We could potentially add some typemaps which fixed this, but not sure it
is worth it.

However what I envisioned was that one could:

   time = Constant(0.0)
   time_dep_expression1 = Expression("sin(t)", t=time)
   time_dep_expression2 = Expression("cos(t)", t=time)

   time_dep_expression1(0,0,0) -> 0.0
   time_dep_expression2(0,0,0) -> 1.0

   time.assign(pi/2)
   time_dep_expression1(0,0,0) -> 1.0
   time_dep_expression2(0,0,0) -> 0.0

However, I just realized that we need to store a shared_ptr in the sub
classed expression for the update to propagate. Then we need to grep and
replace in the generated code such that the first eval become one of the
following:

    values[0] = sin(*t);
    values[0] = sin(((float)*t));

The second is more explicit and should be more robust in a more complex
expression.

If you have a suggestion on how to regexp->replace all t variables in an
expression with something I sketched above I am all ears.

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

Nice! I have heard uflacs will eventually replace all of FEniCS :)

Johan

> Martin
> 
> 
> 
> On 15 February 2013 12:04, Johan Hake <hake.dev@xxxxxxxxx
> <mailto: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
>     <mailto: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>
>     >>> <mailto: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
>     <mailto:dolfin@xxxxxxxxxxxxxxxxxxx>
>     >> Unsubscribe : https://launchpad.net/~dolfin
>     >> More help   : https://help.launchpad.net/ListHelp
> 
>