dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Wednesday 17 December 2008 23:48:13 Martin Sandve Alnæs wrote:
> On Wed, Dec 17, 2008 at 11:32 PM, Martin Sandve Alnæs
>
> <martinal@xxxxxxxxx> wrote:
> > On Wed, Dec 17, 2008 at 6:35 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> >> On Wed, Dec 17, 2008 at 06:08:14PM +0100, Johan Hake wrote:
> >>> On Wednesday 17 December 2008 17:54:23 Martin Sandve Alnæs wrote:
> >>> > On Wed, Dec 17, 2008 at 5:42 PM, Johan Hake <hake@xxxxxxxxx> wrote:
> >>> > > On Wednesday 17 December 2008 16:34:16 Anders Logg wrote:
> >>> > >> On Wed, Dec 17, 2008 at 01:58:35PM +0100, Martin Sandve Alnæs 
wrote:
> >>> > >> > Using latest hg versions of everything, I'm trying to plot a
> >>> > >> > Function from C++ based on a SFC-generated function space and I
> >>> > >> > get:
> >>> > >> >
> >>> > >> > Failed to read DOLFIN mesh or function XML file for plotting:
> >>> > >> >   *** Error: Unable to find dof map in library:
> >>> > >> > "FiniteElement('Lagrange', 'triangle', 1)".
> >>> > >> > Unable to plot (DOLFIN Python module or Viper plotter not
> >>> > >> > available).
> >>> > >> >
> >>> > >> > Can I suggest using Function::interpolate to make a .vtu file to
> >>> > >> > plot instead of relying on a form compiler specific precompiled
> >>> > >> > element library?
> >>> > >> >
> >>> > >> > Martin
> >>> > >>
> >>> > >> Sounds like a good idea. We now generate Python script that loads
> >>> > >> the Function (or Mesh) from file and then calls Viper from Python.
> >>> > >>
> >>> > >> Does Viper support direct plotting of .vtu files? In that case, we
> >>> > >> would not need to call Python from C++. We could generate a .vtu
> >>> > >> file and then call Viper with that file (using system()).
> >>> > >>
> >>> > >> I don't have time to fix this now, so either find someone to fix
> >>> > >> it or put it on the TODO list.
> >>> >
> >>> > What is in use, the text file or bugzilla?
> >>> >
> >>> > > We could also plot a cpp.Function instead of a dolfin.Function.
> >>> > > That fix would not be so extensive. I had a brief look at it but
> >>> > > couldn't find out where
> >>> > >
> >>> > >   Function(filename)
> >>> > >
> >>> > > was called.
> >>> > >
> >>> > > Johan
> >>> >
> >>> > I also want to write a Function to file in C++.
> >>> > What are the requirements on the FunctionSpace
> >>> > to be able to do that?
> >>>
> >>> I think that the only requirement is that the element should be defined
> >>> in
> >>>
> >>>   dolfin/elements/elements.py
> >>
> >>even
> >> That should only be required for reading.
> >
> > That's probably what I want.
> >
> > The strings there use "triangle" instead of 'triangle' which is what
> > repr("triangle") returns. This doesn't match with the UFL
> > implementation of repr(element), and this is where my current attempt
> > failed.
> >
> > Even when this is fixed, one way or the other, this element library is
> > ffc specific. I don't know exactly how compatible the dofmaps from ffc
> > and sfc are, and I'm not sure how to fix this...
> >
> > Martin
>
> Just a small thought... Is it possible today to provide an existing
> FunctionSpace to a Function that is being read from file?
> Something like (I know this constructor is not there):
>
>     Function f(V, filename);
>
> If it's not possible in any other way, that should be added anyway
> to allow reuse of function spaces across functions. In this case,
> I wouldn't need to worry about the element library since I provide
> my own FunctionSpace.

This constructor would also help when two functions that are defined on the 
same mesh are read from files. They owe different instances of the same mesh, 
making them incompatable during assemble.

Johan