Subject: [Viper-dev] Something fishy in plot/update vmin/vmax

From: Johan Hake <[email-masked]>
Date: Thu, 3 Jul 2008 13:42:39 +0200

Hello!

I think there is a bug in viper relating to the vmin/vmax? 

The color range is saturated quite fast when for example I run 
py4c/sandbox/glennli/pulmonary/solver.py. 

This has also happend in other applications I have, and I therefore do not 
suspect that it is due to the application.

I also recon that when viper.py is byte compiled I get an error for line 519 
where you 

   from vtk.wx.wxVTKRenderWindow import *

import * is only allowed at mudule level. I suppose

   from vtk.wx.wxVTKRenderWindow import wxVTKRenderWindow

will do the trick.

Cheers

Johan

---

From: Johan Hake <[email-masked]>
Date: Thu, 3 Jul 2008 14:57:05 +0200

> I think there is a bug in viper relating to the vmin/vmax?

First the interface to def __init__() is not very clear.

Especially not for backward compatability, when Viper had a specified set of 
arguments instead of *arg, and **kwarg. 

Also if no kwarg is provided aka old style, vmin and vmax will be overloaded 
by x.min() and x.max(), with the following lines in __init__()

 vmin = kwargs.get("vmin", x.min())
 vmax = kwargs.get("vmax", x.max())

Fixing the above problem with vmin and vmax will not fix the overall problem 

Rolling back to changeset ~70 fixed the plot problem I had. When checking 
viper.mapper.GetScalarRange() this is correct, after a fix of the above 
mentioned problem. The viper.x is also updated with correct values, but no 
changes is seen on the plot.

Any clue?

Johan

> I also recon that when viper.py is byte compiled I get an error for line
> 519 where you
>
> _______________________________________________
> Viper-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/viper-dev

---

From: Ola Skavhaug <[email-masked]>
Date: Fri, 4 Jul 2008 00:33:24 +0200

> arguments instead of *arg, and **kwarg. 

Sure, but I am working on extending the stand-alone functionality of Viper
these days, and then the old specific argument list was insufficient.
 
>  vmax = kwargs.get("vmax", x.max())

This was the behaviour earlier as well.
 
> changes is seen on the plot.
 
Yes, it might be related to the warp scalar module. I'm working on a fix.

Thanks for the bug report, btw.

Ola

---

From: Johan Hake <[email-masked]>
Date: Fri, 4 Jul 2008 10:28:41 +0200

On Friday 04 July 2008 00:33:24 Ola Skavhaug wrote:
> > Especially not for backward compatability, when Viper had a specified set
> > of arguments instead of *arg, and **kwarg.
>

Cool! 

> > Also if no kwarg is provided aka old style, vmin and vmax will be
> > overloaded by x.min() and x.max(), with the following lines in __init__()
> >

Yes, if the vmin and vmax was not set by arguments, but if the vmin, and vmax 
are set by *args aka the old way, these are overridden by the above 
statements.

> > mentioned problem. The viper.x is also updated with correct values, but
> > no changes is seen on the plot.
> >
> > Any clue?
>

No probs!

Johan