1000 actors, 4000 links

[Richard Ware]

 Hi, folks.  I'm trying to create a model in the DE domain with 
thousands of actors.
I'm creating the model, and running it, by writing Java code; I'm not 
doing anything
graphical at all.  All the actors are instances of the same Java class 
that extends
DEActor.  Each actor has one input and one output, each with about four 
channels
connecting to other actors (except for a few actors at the "beginning 
edge" and
"ending edge" of the graph, which have no input channels and no output 
channels,

respectively).

 What confuses me and alarms me is that, while the code (step 1) to 
instantiate the
actors and the code (step 3) to run the model executes in a reasonable 
amount of
time, the code (step 2) to wire together all the actors' inputs and 
outputs takes an
amazing amount of time!  I'm trying my program with a steadily larger 
and larger
number of actors, and doubling the number of actors causes the time for 
Step 2
to multiply 8 times!  For example, with 1,000 actors, it took 186 
milliseconds to
instantiate them, 9 minutes and 35 seconds to wire them, and 2 minutes 
to run

the simulation.

 I've stepped through my own code, and the Ptolemy code, trying to find
which code might be taking a long time during link-wiring, and
I've gotten some glimpses.  For one thing, every
time you add one new link to a model, Ptolemy does a lot of rechecking of
the graph topology and model integrity--that makes me wish there were a
version of method CompositeEntity.connect( ComponentPort, ComponentPort )
that would take a bunch of links, add them all in, then check model
integrity.  Also, it looks to me like some of the checking may be 
related to checking
the model's safety for modification while it's running.  I don't want to 
modify it
while it's running; is there a way for me to configure something to 
signify that,

so that Ptolemy won't check the model so thoroughly?

 About the only other glimpse I've gotten is that method
DEDirector._computePortDepth() seems to take up a lot of time.

 Of course I will appreciate any information or advice you can give me
and how to make linking take less time.

Respectfully,

Richard Ware



Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

A few questions

[Richard Ware]

 1) It would be frowned on, wouldn't it, for one actor
to fire another "directly" by calling fireAt(), fireAtRelativeTime()
or fireAtCurrentTime() and giving a reference to the target
actor as an argument to the method call?  I figure it would
be frowned on, because in the Ptolemy model actors
communicate with other actors only through their ports, and
shouldn't be directly aware of other actor objects.

 The correct approach would be to design my model as a
whole so that the actor communicates with others by sending
event-tokens through its output ports, right?

 2) In the DE domain, I've read about "pure-event" tokens
(and so far, that's all I've used).  How do I instantiate a token
that contains both a bit of data and a time-stamp?  Is there a
particular page in one of the documents that I should have
paid more attention to?

 3) Is there a way, in the actor's fire method, to instantiate and
send an event-token whose time-stamp is in the future?  All
your examples seem to take a different approach:  the actor
requests itself to be fired in the future, and on that firing, it 
sends

the usual kind of event-token, one with a present-time-stamp.

 Am I trying to do something frowned on again?  ;)

Thanks,

Rich Ware




Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Simulation-time

[Richard Ware]

 I'm working with the DE domain.  Simulation-time is expressed as a
floating-point number (a Java double), and the simulation usually starts
at sim-time 0.0 .  I think I read somewhere in the documentation that the
sim-time scale is 1.0 sim-time equals 1 second.

 Is there any problem with interpreting the sim-time scale as anything
else we like, for instance 1.0 sim-time equals 1 day, 1 hour, 1 minute or
1 millisecond?

 And would there be any problem if I make my simulation start later 
than 0.0

by having the actors' initialize() methods call

double sim_start = 3.0;
director.fireAt( this, sim_start );

instead of

director.fireAtCurrentTime( this );

?



Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

ptolemy.actor.util.Time

[Richard Ware]

 When I do this,

Time a = ourDirector.getModelTime();
Time b = null;
boolean comparison = a.equals( b );

I get a NullPointerException.

 That isn't what the equals() method of a Java object is supposed to 
do.  If
given null as the argument, it's supposed to calmly return the boolean 
value "false".





Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: 10000 actors, 40000 links

[Richard Ware]

Richard Ware wrote: 

 Here's my idea:
   - Override .equals() in NamedList . .

 Damn!  I meant to say "Nameable".




Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: 10000 actors, 40000 links

[Richard Ware]

Richard Ware wrote:
 I'm going to try using a modified form of NamedList, based on the 
following:


   - Keep all the present code using the internal LinkedList.
   - Also keep the named-object references in an internal HashSet, 
hashing on the name.
 I meant to say, add an internal HashMap that maps the object names to 
the named-object

references.
   - Since I won't be using a Tree, I can forget about meddling with 
Nameable.equals() .



Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: 10000 actors, 40000 links

[Richard Ware]

Edward A. Lee wrote:

Why not use LinkedHashSet?  It would seem that this would
solve the problem without a shadow data structure.
Having two data structures representing the same information
introduces a major risk: that they get out of sync.  You have
to think through all possible exception scenarios that could
lead to an object being in one set and not in the other...
This could be quite tricky.  Also, I would assume that
LinkedHashSet would be more efficient...
  
 LinkedHashSet doesn't have a method like LinkedList's |void| |*add 
*(int index, 
E 
 element)| 
,

which NamedList needs.



Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Class SharedParameter

[Richard Ware]

 Is there a class ptolemy.moml.SharedParameter?  Should I be using
ptolemy.actor.parameters.SharedParameter instead?



Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Multiple models, serially or concurrently

[Richard Ware]

1) Do I remember correctly that Ptolemy does not in any way support
Java concurrency or multi-threading?  If so, then I would assume that one
couldn't safely run 2 models in one JVM, even if each had its own
instances of TypedCompositeActor, Manager, Director, etc.  If one
wanted concurrency, one would run separate JVM's, each with one
model that would have no contact with any other model.  Right?

2)  If (in one JVM) I had a program running that wanted to run
several models (similar to each other), one after the other, how much reuse
of Ptolemy instances makes sense?  Would you recommend nulling
all references after each model run, and instantiating all Ptolemy objects
fresh?  Or would it make any sense to reuse the same
TypedCompositeActor, Manager, Director, etc?  Regardless of
which approach I use, I plan to delete all actors from the first model run
and create all actors for the second run fresh, for reasons involving the
nature of my simulation.  Does Ptolemy have a way to scrub all actors
out of a model, allowing the creation of new ones?

 I look forward to your clarifications.

    Richard Ware






Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: 8th Biennial Ptolemy Miniconference: April 16, 2009

[Richard Ware]

  Can you guys remind me whether there's any architectural
reason to avoid overriding equals() (and hashCode() ) when
writing an actor in Java?  Thanks!

 Rich Ware
 MOCASystems

Re: equals() and hashCode() in Ptolemy Actors

[Richard Ware]

  I assume then that I won't break the framework by writing equals()
and hashCode() in my actor (because some of my other code wants
to use them).

  Thanks, Christopher!

On Mon, Oct 27, 2008 at 12:40 PM, Christopher Brooks
<[EMAIL PROTECTED]>wrote:

> Hi Richard,
> Actors usually don't have equals() and hashCode() methods.
> However, if you define a custom token, like
> actor.lib.security.KeyToken, then the custom token should
> have equals() and hashCode() methods.
>
> _Christopher
>

Bug?

[Richard Ware]

  While reading the Ptolemy code, I found the following anomaly:

FloydWarshallAllPairShortestPathStrategy implements
AllPairShortestPathAnalyzer.

FloydWarshallCycleExistenceStrategy implements
CycleExistenceAnalyzer.

FloydWarshallNegativeLengthCycleStrategy implements
NegativeLengthCycleAnalyzer.

FloydWarshallTransitiveClosureStrategy implements
TransitiveClosureAnalyzer.

But
FloydWarshallZeroLengthCycleStrategy implements, not
ZeroLengthCycleAnalyzer, but
NegativeLengthCycleAnalyzer.

  Is this a bug?  Or just a design choice that doesn't
follow the pattern?


Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: ptolemy-hackers-requ...@ptolemy.eecs.berkeley.edu