dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Feb 15, 2006 at 03:38:52PM +0100, Johan Jansson wrote:
> Hi,
> 
> Now Function IO (DOLFIN XML format) is implemented. I've only done
> simple tests, but there's no reason it shouldn't work for general
> cases.
> 
> I think the best way to implement input for VTK is as a conversion
> utility to DOLFIN XML. This utility could be written in Python, where
> there exists a VTK module (to avoid unnecessary DOLFIN library
> dependencies).

We could add this to dolfin-convert (in src/utils/convert) so one can
do

    dolfin-convert function.vtu function.xml

> If a FiniteElement knows the FIAT name of the element, then it should
> be possible to read a Function and generate the finite element in
> Python (and use it in PyDOLFIN).

We should probably use the FFC name. FFC already identifies elements
with strings, but FIAT has a class for each element: Lagrange.Lagrange
instead for "Lagrange".

> Projections could also be done in PyDOLFIN in a similar fashion (by
> dynamically generating the appropriate form, see the import_form()
> example I posted earlier).
> 
> I think if we want to rely on code generation, then we also need to
> provide functionality for dynamically using the generated code. This
> could be done also in C++ DOLFIN, but I think it's by far simpler in
> Python. Anyway, the functionality exists, so we can start using it to
> provide basic functionality (such as projection). But then we would
> have made a sort of design shift, in that you cannot achieve all the
> basic functionality by only using the C++ interface. I guess we need
> to decide if this is what we want.

Perhaps if you are willing to use the C++ interface, you are also
willing to do more stuff yourself, like precompiling the forms. But I
think we should try to keep the C++ interface as automatic and simple
as possible; even if the Python interface can go much further, we
don't need to give up on simplicity on the C++ side.

There could be a limited set of pregenerated elements that we include
with DOLFIN. They can all be done automatically so it's no big deal.
Currently, we have P1Tri and P1Tet, but we could add some more: PqTri
and PqTet for a suitable range of q. If DOLFIN reads in a Function and
needs an element, it will know if the element exists. Otherwise, it
can generate a suitable message that the element needs to be
precompiled.

Perhaps there should be an easy way to compile just a FiniteElement
with FFC, without needing to declare a form.

/Anders

>   Johan
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> 

-- 
Anders Logg
Research Assistant Professor
Toyota Technological Institute at Chicago
http://www.tti-c.org/logg/