Subject: [Viper-dev] Feature/interface request

From: Anders Logg <[email-masked]>
Date: Tue, 25 Mar 2008 21:45:14 +0100

I have a suggestions for a change in the way plot() behaves.

When plotting the solution in a time loop, it seems one has to do
something like this to get things to work as expected, which is to run
the simulation and update the plot in each time step (without
pausing):

  u = Function(...)

  while t < T:

      # Compute solution
      ...

      # Plot solution
      if t > 0.0:
          update(u)
      else:
          plot(u, interactive=False)

      t += k

I'd like it better if we could do

  u = Function(...)

  while t < T:

      # Compute solution
      ...

      # Plot solution
      plot(u)

This could be handled by setting the default value for interactive to
False and let plot remember (for each window) which object was last
plotted and in that case do an update instead of creating a new plot.

Could that work?

-- 
Anders

---

From: Ola Skavhaug <[email-masked]>
Date: Tue, 25 Mar 2008 22:44:34 +0100

> plotted and in that case do an update instead of creating a new plot.

Certainly. I could let plot be "smart", and test for equality in a list of
plot objects. In case of no equalities found, a new plot window can pop up. If
an equality is found, the corresponding plot window is updated. Is this what
you have in mind?
 
> -- 
> Anders
> _______________________________________________
> Viper-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/viper-dev

---

From: Anders Logg <[email-masked]>
Date: Tue, 25 Mar 2008 22:54:16 +0100

> an equality is found, the corresponding plot window is updated. Is this what

Yes!

--
Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Tue, 25 Mar 2008 23:32:27 +0100

>  > an equality is found, the corresponding plot window is updated. Is this what

"Equality" should then be "a is b", not "a == b", which makes it a
no-cost operation.

But: I don't really see the point in your example. I'd just do this:

u = Function(...)

# Plot initial condition
plot(u)

while t < T:

     # Compute solution
     ...

     # Plot solution
     update(u)

     t += k

-- 
Martin

---

From: Ola Skavhaug <[email-masked]>
Date: Tue, 25 Mar 2008 23:47:17 +0100

> "Equality" should then be "a is b", not "a == b", which makes it a

Good point.

> But: I don't really see the point in your example. I'd just do this:
 
I guess this is a matter of taste. I'm ok with either solution.

Ola

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Tue, 25 Mar 2008 23:56:49 +0100

> I guess this is a matter of taste. I'm ok with either solution.

Anyway, the solutions don't conflict.

But maybe, after Johannes is done with the build system, trilinos
support in dolfin, and evt other more important stuff I don't know
about, he can look at harmonizing viper and easyviz? He's in a good
position to do that I think, being one of the main developers of
easyviz to begin with.

F.ex.:

from viper import *

u = Function(...)
p = Function(...)

# Plot initial conditions
figure(0)
plot(u)
figure(1)
plot(p)

while t < T:

    # Compute solution
    ...

    # Plot solution
    figure(0)
    plot(u)
    figure(1)
    plot(p)

    t += k

The use of "figure" and "hold" like in matlab is familiar to most
people and fairly flexible and simple.

--
Martin

---

From: Anders Logg <[email-masked]>
Date: Wed, 26 Mar 2008 07:04:29 +0100

> But: I don't really see the point in your example. I'd just do this:

I think this doesn't work for two reasons:

1. If the solution is initially zero (which it is for me and probably
quite often), then you won't see anything since Viper scales the plot
to fit the first plot. (I think this is what happens, at least I don't
see anything when used like this.)

2. You need to add interactive=False (I think) to the first plot.

I addition, just calling plot is easier, and more "MATLAB-like".

-- 
Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 26 Mar 2008 08:26:02 +0100

>  see anything when used like this.)

I see, but this isn't really solved with your approach.
The color scale problem arises if u^{k} > u^{0} for a timestep k,
which you only change to u^{k} > u^{1}. Or should plot scale the
colors in each step separately unless a color scale has been chosen?
Because choosing a color scale manually (and correctly...) up front
is the only way to get consistent color scales with all values within the range.

>  I addition, just calling plot is easier, and more "MATLAB-like".

Agree. Combined with "figure(i)" it would be great.

--
Martin

---

From: Ola Skavhaug <[email-masked]>
Date: Wed, 26 Mar 2008 08:54:25 +0100

> Agree. Combined with "figure(i)" it would be great.

And I will, of course, accomodate the users :)

Ola

---

From: Anders Logg <[email-masked]>
Date: Wed, 26 Mar 2008 17:41:48 +0100

> And I will, of course, accomodate the users :)

Nice!

-- 
Anders