Kepler

Am I to understand that Hydrant has this code already?
Cool.

It seems a little heavyweight to require Hydrant here,
perhaps a lighter weight solution, such as adding a MoML filter
could be used? I'd be willing to fold changes into the
ptII tree to more easily support this.

What's in the Hydrant is just a new MoML filter and a set of new classes which extend display related actors, like Display and PlotterBase, and rewrite their postfire()/wrapup() to write the data to files.

Will it be the same way if support it from PTII?

This bug needs to be fixed in version 2.4. I have tried locally using hydro library. It works.

We can either have a new module called hydro, or put it in existing modules.

The issue here is to make it possible to capture Display and Plotter data.

A team of CMU students modified how the plotter and Display actors work.

Basically, we now have ptolemy.actor.lib.gui.DisplayInterface.

actor.lib.gui.Display has
protected DisplayInterface _getImplementation()
which reads
ptolemy/actor/ActorModule.properties

The thing to do would be to make it so that we can substitute in a different
ActorModule.properties file that uses different actors as an implementation.

To do this, we would need a class that calls
ptolemy.actor.injection.ActorModuleInitializer.setInitializer()

The class would need to be invoked via the command line.

I changed this from a blocker to an enhancement because Kepler works as
defined, so this is not a bug, it is missing functionality.

I can see how it would be important to get this done, so I've left it P1.

Hi Christopher,

Thanks for your info. I tried a simple DisplayInterface implementation for saving the content to a file. It works! :)

Currently, Hydrant also supports this function for ImageJActor, MonitorValue and ImageDisplay actors. If we adopt the similar DisplayInterface solution for these actors, we need to re-write these actors.

Jianwu,
Cool that it worked!

It might be more work to use code like the DisplayInterface code, but the
DisplayInterface style will be supported in the future. It is a more
elegant solution than the filtering solution that is in Hydrant.

So, given a choice, I say move forward with ImageJActor, MonitorValue
and ImageDisplay with the DisplayInterface style.

However, I'd understand if you wanted to fall back to the filter style
that is in Hydrant.
I'm not so sure I want that filter-style code in the ptII tree though.

Christopher,

I agree that DisplayInterface solution is a better one, although it needs more work. I also prefer this way.

To move forward, I can update ImageJActor actor first since it is in Kepler. After that, we can discuss how to update MonitorValue and ImageDisplay in Ptolemy.

Now it works with Display, Plot and ImageJ actors at version 30211. A new module called "display-redirect" is added to Kepler suite to support their batch execution and file saving.

Hi Christopher,

Hydrant also used to support the batch execution of MonitorValue and ImageDisplay actors in Ptolemy. But these two actors haven't use the similar way like display implementation. Do you plan to update these actors in Ptolemy using the same way? If so, I'm happy to provide their batch execution support.

I saw that the hydrant code was checked in awhile ago.

I have no plans to modify MonitorValue and ImageDisplay so that they are
similar to Display. Someone else would need to make the changes in Ptolemy II.

If the Hydrant code works and you don't want to make the changes, then we
should stick with the Hydrant code. I prefer the method we are using with
Display over adding the Hydrant code, but I don't have time to make further
changes. The reason I prefer updating MonitorValue and ImageDisplay is because
the amount of code will be smaller than the Hydrant code and thus MonitorValue
and ImageDisplay are less likely to have bugs and are easier to maintain.

I updated ptolemy version 64086 and kepler version 30298 to support redisplay for MonitorValue and ImageDisplay actors.

Closing the bug.

Original Bugzilla ID was 3997