← Back to team overview

dolfin team mailing list archive

  1. dolfin team
  2. Mailing list archive
  3. Message #19620

Re: Providing rank to tensor(vector) valued Expression

  Thread Previous • Date Previous • • Thread Next 


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. 

Garth


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


What do you mean by never used in a form? What's it used for if not
in a form?


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.


He he no need to take that disc one more time.



Ok :)al po


The point is that a user can optionally provide a FiniteElement. In
this case the expression will get the correct value_size.




My point was simply that it should not be required.



My original point from looking at the doc string  was less subtle
than these. It was that doc string doesn't make clear that a user
can provide a finite element to a non-JIT Expression subclass,
thereby prescribing the space in which the expression should be
interpolated rather than letting FFC decide.

Garth



-- Marie


_______________________________________________ Mailing list:
https://launchpad.net/~dolfin Post to     :
dolfin@xxxxxxxxxxxxxxxxxxx Unsubscribe :
https://launchpad.net/~dolfin More help   :
https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~dolfin
Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~dolfin
More help   : https://help.launchpad.net/ListHelp


--
Anders

Follow ups

References

  Thread Previous • Date Previous • • Thread Next