dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Sep 05, 2010 at 03:50:37PM +0100, Garth N. Wells wrote:
>
>
> On 05/09/10 15:28, Anders Logg wrote:
> >On Sun, Sep 05, 2010 at 11:02:08AM +0100, Garth N. Wells wrote:
> >>
> >>
> >>On 05/09/10 10:29, Marie Rognes wrote:
> >>>On 05. sep. 2010 00:00, Johan Hake wrote:
> >>>>On Sep 4, 2010, at 11:16, Marie Rognes<meg@xxxxxxxxx>   wrote:
> >>>>
> >>>>
> >>>>>On 04. sep. 2010 18:26, Johan Hake wrote:
> >>>>>
> >>>>>>On Saturday September 4 2010 03:54:35 Marie Rognes wrote:
> >>>>>>
> >>>>>>
> >>>>>>>On 04. sep. 2010 01:36, Johan Hake wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>>Hello!
> >>>>>>>>
> >>>>>>>>Garth found an ambiguity in the Expression doc string
> >>>>>>>>regarding how a user should initiate a user defined
> >>>>>>>>Expression (not a compiled one) in Python. If the
> >>>>>>>>Expression is vector or tensor valued the user need to
> >>>>>>>>provide information about this.
> >>>>>>>>
> >>>>>>>>This can be done in two ways. Either overload the dim
> >>>>>>>>method or provide a ufl FiniteElement while instantiating
> >>>>>>>>the Expression. Neither of these methods are documented in
> >>>>>>>>the docstring.
> >>>>>>>>
> >>>>>>>>In the mixed poisson demo both dim and rank are overloaded.
> >>>>>>>>I think rank is not needed (works fine without). However
> >>>>>>>>dim is just a method introduced to be able to automatically
> >>>>>>>>select a FiniteElement.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>Thanks for bringing this up -- evidently I'm confused.
> >>>>>>>
> >>>>>>>
> >>>>>>Well, me too. Ever since Anders introduced the automatic
> >>>>>>selection of elements for the Expressions, I have been some
> >>>>>>what confused.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>Well, that part made perfect sense to me --- I think ;)
> >>>>>
> >>>>:)
> >>>>
> >>>>
> >>>>>>>>First I am not sure dim is the correct name. We could use
> >>>>>>>>value_size as this is present in the GenericFunction
> >>>>>>>>interface for just this purpose. Second I am not sure
> >>>>>>>>overloading a method is the best and most clear way to
> >>>>>>>>provide this information. Maybee he could do it while
> >>>>>>>>instantiating the Expression instead?
> >>>>>>>>
> >>>>>>>>class BoundarySource(Expression): def eval_data(self,
> >>>>>>>>values, data): g = sin(5*data.x()[0]) values[0] =
> >>>>>>>>g*data.normal()[0] values[1] = g*data.normal()[1]
> >>>>>>>>
> >>>>>>>>s = BoundarySource(value_size=2)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>I don't really like the name value_size, but this looks
> >>>>>>>natural to me. What would it be for matrix-valued functions?
> >>>>>>>
> >>>>>>>
> >>>>>>As I have understand it, value_size is the size of the values
> >>>>>>array passed to the Expression. So that would then be:
> >>>>>>
> >>>>>>value_size = m x n
> >>>>>>
> >>>>>>I am not totally happy with the above code as the class should
> >>>>>>contain everything it needs to be instantiated correctly.
> >>>>>>
> >>>>>>Would it make more sense to change the name of dim to
> >>>>>>value_size?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>Exactly what do you mean here? Keep needing to supply a method
> >>>>>"dim", but renaming it to "value_size" ? (I still don't find the
> >>>>>name value_size very intuitive.)
> >>>>>
> >>>>Something like that. The point is that a user need to provide this
> >>>>information so the Expression can be properly evaluated.
> >>>>
> >>>
> >>>
> >>>How about
> >>>
> >>>s = Expression(value_shape=I)
> >>>
> >>>where I is a multiindex such as (m,) or (m, n) or (m, n, q, ...)
> >>>etc. Maybe with the options of
> >>>
> >>>Expression(value_shape=m)<=>   Expression(value_shape=(m,))
> >>>
> >>>And no overloading of dim or rank?
> >>>
> >>
> >>Looks very Python centric. The issue of the shape isn't Python
> >>specific - it needs to be refined/sorted out in the C++ interface
> >>too.
> >
> >Is there a need for that? The C++ Expression class has these two
> >virtual functions:
> >
> >   /// Return value rank
> >   virtual uint value_rank() const;
> >
> >   /// Return value dimension for given axis
> >   virtual uint value_dimension(uint i) const;
> >
> >They make perfect sense and have a 1-1 mapping to the UFC interface.
> >
>
> Instead of refined I meant documented. For example, the relationship
> between a tensor and its flattened array representation.

ok. Yes, we need that (as part of the DOLFIN) documentation but I
think it is already defined in the UFC documentation.

--
Anders