Subject: [Viper-dev] Plotting from dolfin in C++

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 17 Dec 2008 13:58:35 +0100

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

---

From: Anders Logg <[email-masked]>
Date: Wed, 17 Dec 2008 16:34:16 +0100

> of relying on a form compiler specific precompiled element library?

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.

-- 
Anders

---

From: Johan Hake <[email-masked]>
Date: Wed, 17 Dec 2008 17:42:24 +0100

On Wednesday 17 December 2008 16:34:16 Anders Logg wrote:
> > 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
>

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

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 17 Dec 2008 17:54:23 +0100

>> I don't have time to fix this now, so either find someone to fix it or

What is in use, the text file or bugzilla?

> not be so extensive. I had a brief look at it but couldn't find out where

I also want to write a Function to file in C++.
What are the requirements on the FunctionSpace
to be able to do that?

Martin

---

From: Johan Hake <[email-masked]>
Date: Wed, 17 Dec 2008 18:08:14 +0100

On Wednesday 17 December 2008 17:54:23 Martin Sandve Alnæs wrote:
> > 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 think that the only requirement is that the element should be defined in 

  dolfin/elements/elements.py

Johan

---

From: Anders Logg <[email-masked]>
Date: Wed, 17 Dec 2008 18:35:20 +0100

> What is in use, the text file or bugzilla?

Both, and both are mostly ignored. :-)

Our problem is that everyone is occupied with development. It is rare
that I find time to look at TODO lists.

Anyway, I think it would be good if we could use Bugzilla more. It is
built to handle bug reports and requests and it's more visible than
the TODO file.

> > not be so extensive. I had a brief look at it but couldn't find out where

You mean from the generated plot script?

Look for the following lines in plot.cpp:

  plot_class = eval(plot_type)
  f = plot_class(data_name)

> What are the requirements on the FunctionSpace

No requirements other than that the FunctionSpace exists. We end up
calling interpolate_vertex_values.

PS: Maybe interpolate_vertex_values is a good name for one of the
interpolate functions.

-- 
Anders

---

From: Anders Logg <[email-masked]>
Date: Wed, 17 Dec 2008 18:35:53 +0100

>   dolfin/elements/elements.py

That should only be required for reading.

-- 
Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 17 Dec 2008 23:25:18 +0100

> calling interpolate_vertex_values.

That's the vtk file writing that I fixed up recently, but I meant storing
an actual Function which can be read back, not its interpolant.

> PS: Maybe interpolate_vertex_values is a good name for one of the

I think that's clear and good.

Martin

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 17 Dec 2008 23:32:04 +0100

> 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

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 17 Dec 2008 23:48:13 +0100

On Wed, Dec 17, 2008 at 11:32 PM, Martin Sandve Alnæs
<[email-masked]> wrote:
>>even

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.

Martin

---

From: Johan Hake <[email-masked]>
Date: Thu, 18 Dec 2008 08:27:36 +0100

On Wednesday 17 December 2008 23:48:13 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:
> >>> > >> >
> >>> > >> > 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.
> >>> > >>
> >>> > >> 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.
> >>> >
> >>> > > 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
> >>> >

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