dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sat, Sep 04, 2010 at 08:16:43PM +0200, Marie Rognes 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.)

We have value_rank and value_dimension in the UFC interface. Those are
well defined and well documented. value_size is not something the user
should be worried about, but it is something that comes up in the code
again and again when allocating arrays:

  int value_size = 1;
  for (int i = 0; i < value_rank; i++)
    value_size *= value_dimension(i)

Another option would be to set value_shape which is

  int value_shape[value_rank];
  for (int i = 0; i < value_rank; i++)
    value_shape[i] = value_dimension(i)

--
Anders



> >>> Or just use the FiniteElement which is a litle bit over kill but already
> >>> possible as it is.
> >>>
> >>>   s = BoundarySource(element=BDM.ufl_element())
> >>>
> >>> What you say?
> >>>
> >> When prescribing an element (or a function space) to anything that
> >> resembles a function, I assume that the function (in this case, the
> >> Expression) is interpolated into the function space defined by that
> >> element. Is that correct?
> >>
> > Yes, that is correct. We need a FiniteElement to be able to initiate the
> > ufl.Coefficient. If not provided we automatically choose one based on (for now
> > the dim method) what the user provides.
> >
> >
>
>
> But no element space is needed in this case. If the "s" is never used in
> a form (as is the case in the mixed Poisson example), then it only needs
> to be evaluate-able. Hence, we should not require an element or function
> space to be set for Expressions. I seem to remember this being one of
> the main points with the Function vs Expression design.
>

--
Anders