Subject: [Viper-dev] C++ plotting broken (even in serial)

From: Anders Logg <[email-masked]>
Date: Tue, 15 Sep 2009 12:56:29 +0200

When plotting a <function_plot_data> object from file, Viper just
plots the mesh, not the function.

Is this a bug in Viper?

--
Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Tue, 15 Sep 2009 12:59:24 +0200

> plots the mesh, not the function.

I don't know. It's a pain to find out because there is no error message 
and DOLFIN cleans up the plot files afterwards. It happens to me so 
often that I'm not going to bother fixing it any more.

Garth

> --
> Anders
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Viper-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/viper-dev

---

From: Anders Logg <[email-masked]>
Date: Tue, 15 Sep 2009 13:03:16 +0200

> often that I'm not going to bother fixing it any more.

I don't think DOLFIN cleans up the plot files. The file is created in
the current directory and is named dolfin_plot_data.xml.

--
Anders

---

From: Ola Skavhaug <[email-masked]>
Date: Tue, 15 Sep 2009 14:31:22 +0200

> the current directory and is named dolfin_plot_data.xml.

The problem here is the restructuring of the swig interface; the
rshift operator on FunctionPlotData is defined before the definition
of FunctionPlotData. This causes swig to ignore the rshift (and
lshift) operator for FunctionPlotData, and hence the lines

f = File(filename)
f >> FunctionPlotData()

fails.

Ola

> --
> Anders
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkqvdHQACgkQTuwUCDsYZdE7QACfeE0YBtDkgF8UCT98L/XrTijV
> esUAn3+GtnSrAMEiS6s8bfiFJT4gVPU+
> =fclj
> -----END PGP SIGNATURE-----
>

-- 
Ola Skavhaug

---

From: Johan Hake <[email-masked]>
Date: Tue, 15 Sep 2009 14:32:22 +0200

> plots the mesh, not the function.

I'am on to it

Probably a regression from my restructuring of the SWIG interface...

Johan

---

From: Johan Hake <[email-masked]>
Date: Tue, 15 Sep 2009 14:48:55 +0200

> lshift) operator for FunctionPlotData, and hence the lines

Should be fixed now

Johan

---

From: Ola Skavhaug <[email-masked]>
Date: Tue, 15 Sep 2009 15:09:21 +0200

>> lshift) operator for FunctionPlotData, and hence the lines

Latest viper commit should make things work again.

Ola

-- 
Ola Skavhaug

---

From: Anders Logg <[email-masked]>
Date: Tue, 15 Sep 2009 16:29:10 +0200

> Latest viper commit should make things work again.

Works nicely now. Thanks!

--
Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Mon, 21 Sep 2009 19:32:41 +0100

This issue has returned.

Garth

---

From: Johan Hake <[email-masked]>
Date: Mon, 21 Sep 2009 21:00:08 +0200

> This issue has returned.

I think the issue is at the viper side this time. 

  f = File(filename)
  data = FunctionPlotData()
  f >> data

works fine.

Johan

> >>>>> I don't know. It's a pain to find out because there is no error
> >>>>> message and DOLFIN cleans up the plot files afterwards. It happens to
> >>>>> me so often that I'm not going to bother fixing it any more.
> >>>>>
> >>>>> Garth
> >>>>

---

From: Ola Skavhaug <[email-masked]>
Date: Tue, 22 Sep 2009 09:28:01 +0200

>  data = FunctionPlotData()

The general problem with DOLFIN and Viper is the changing interface of
DOLFIN. This, together with the desired viper use of

viper some_plot_data.xml

which essentially leads to Python code a-la

try:
 plot_function_plot_data()
except:
 pass
try:
 plot_mesh_function()
except:
 pass
try:
 plot_mesh()
except:
 raise IOError("Could not find anything to plot")

makes life hard.

In general, the problem as seen from the Python side is that we need
to spesify the type of object read from file. Being a dynamically
typed language, the following code (or similar) is possible:

plot(File(filename).read())

which would make is much simpler to issue a sound error message from Viper.

In my view, the problem is that we haven't code for extracting type
info from a DOLFIN xml file. A simple reader that extracts and reports
this would be nice to have.

f = File(filename)
info = XMLFileInfo(f)
print info
(FunctionPlotData, Mesh)
data = info[0]() # Construct an empty FunctionPlotData instance
mesh = info[1]() # Construct an empty Mesh.
[...]

-- 
Ola Skavhaug

---

From: "Garth N. Wells" <[email-masked]>
Date: Tue, 22 Sep 2009 08:41:52 +0100

> which would make is much simpler to issue a sound error message from Viper.

I added a Blueprint to Launchpad on this,

     https://blueprints.launchpad.net/fenics-viper/+spec/plot-type

> this would be nice to have.

I've said a bunch of times already (but without a response) that we can 
already write to the VTK XML format, and Viper is based on VTK which can 
of course parse its own XML files, so why aren't we just using the VTK 
format? The process is essentially what is described above and would 
require minimal work. See

     https://blueprints.launchpad.net/fenics-viper/+spec/vtk-files

Garth

---

From: Ola Skavhaug <[email-masked]>
Date: Tue, 22 Sep 2009 10:04:58 +0200

On Tue, Sep 22, 2009 at 9:41 AM, Garth N. Wells <[email-masked]> wrote:
> already write to the VTK XML format, and Viper is based on VTK which can of
> course parse its own XML files, so why aren't we just using the VTK format?
> The process is essentially what is described above and would require minimal
> work. See
>

Yes, I agree that this is an alternative solution, and possibly the
best. I have it somewhere on my stack, but I don't except to start
working on it for quite some time. As a matter of fact, plain Viper
has this already for simple unstructured meshes and scalar fields. The
challenge is to allow other types of plot objects to be read from vtk
files as well (i.e. vector fields, cell valued fields, and 2d plots).

The functionality to poll an XML file for its contents would still be
nice to have, for instance if you want to make a simple GUI layer on
top of DOLFIN and allow flexible file input.

Ola

-- 
Ola Skavhaug