Port-Parameters half-work with composite actors
Under the SDF Director, I can create a Composite Actor containing a Port-Parameter and a Display actor. There are 4 cases, which will be attached:
1. Port-Parameter is directly linked to a Display actor. Kepler error.
2. Port-Parameter is directly linked to a Display actor, an Expression actor in the outer workflow is directly linked to the Port-Parameter. Works as expected.
3. Port-Parameter not linked to the Display actor, an Expression in the Composite Actor that repeats the Port-Parameter value is directly linked to the Display actor. No Expression actor in the outer workflow. Works as expected.
4. Port-Parameter not linked to the Display actor, an Expression in the Composite Actor that repeats the Port-Parameter value is directly linked to the Display actor, an Expression actor in the outer workflow is directly linked to the Port-Parameter. Kepler error.
#2 Updated by Christopher Brooks over 11 years ago
PortParameters work with opaque composite actors (composite actors
that have directors), but not transparent composite actors.
The class comment for PortParameter says:
There are a few situations where PortParameter might not do what
- If it is used in a transparent composite actor, then a token provided
to a PortParameter will never be read. A transparent composite actor
is one without a director.
Workaround: Put a director in the composite.
- Certain actors (such as the Integrator in CT) read parameter
values only during initialization. During initialization, a
PortParameter can only have a value set via the parameter (it
can't have yet received a token). So if the initial value of the
Integrator is set to the value of the PortParameter, then it will
see only the parameter value, never the value provided via the
Workaround: Use a RunCompositeActor to contain the model with the
Also, there was this thread in November 2007 on ptdevel:
It is sort of a zen thing, "The port is connected, yet it is
not connected" :-)
I have sort of a wacky view of PortParameters in that I see them to be
"like" Ports and Parameters, yet also not like either Ports or
Parameters. In this case the PortParameter is not actually a Port at
I agree that it is confusing. Perhaps the PortParameter
constructor should look for a director in the container and
print a message if there is no director. This seems a little
I'm not that fond of PortParameters, they do seem fragile.
However, they are very powerful.
My problem is that test.const IS CONNECTED, despite the message (at
least on my display). Putting a SDF Director inside the Composite does
fix the problem.
Christopher Brooks wrote:
> Dan writes:
>> Hi Christopher,
>> We have recently run into some problems using the PortParameter in
>> Kepler (example: deleting a PortParamter seems to really trash Kepler!)
>> So I thought I would try a simple workflow in Ptolemy (attached). This
>> is a SDF model with a constant feeding a PortParameter inside a
>> Composite. Inside the Composite the PortParameter name is used in
>> another constant connected to a Display.
>> When I try running this in VergiI I get an error that the SDF
>> scheduler found disconnected actor (the external constant). It sure
>> doesn't look disconnected! Any ideas on what's up?
> Hi Dan,
> The error message is:
> ptolemy.actor.sched.NotSchedulableException: SDF scheduler found disconne
cted actors! Usually, disconnected actors in an SDF model indicates an error
. If this is not an error, try setting the SDFDirector parameter allowDisco
nnectedGraphs to true.
> Unreached Actors:
> Reached Actors:
> .test.CompositeActor.Const .test.CompositeActor.Display
> at ptolemy.domains.sdf.kernel.SDFScheduler._solveBalanceEquations(SDFSc
> at ptolemy.domains.sdf.kernel.SDFScheduler._getSchedule(SDFScheduler.ja
> at ptolemy.actor.sched.Scheduler.getSchedule(Scheduler.java:188)
> at ptolemy.domains.sdf.kernel.SDFDirector.preinitialize(SDFDirector.jav
> at ptolemy.actor.CompositeActor.preinitialize(CompositeActor.java:1047)
> at ptolemy.actor.Manager.preinitializeAndResolveTypes(Manager.java:912)
> at ptolemy.actor.Manager.initialize(Manager.java:578)
> at ptolemy.actor.Manager.execute(Manager.java:321)
> at ptolemy.actor.Manager.run(Manager.java:1070)
> at ptolemy.actor.Manager$3.run(Manager.java:1111)
> The problem is that test.Const is not connected. One workaround
> is to set the "allowDisconnectedGraphs" parameter in the SDF Director.
> Another workaround is to put a SDF director inside the CompositeActor.
> The PortParameter class docs say:
> There are a few situations where PortParameter might not do what
> you expect:
> If it is used in a transparent composite actor, then a token provided
> to a PortParameter will never be read. A transparent composite actor
> is one without a director.
> Workaround: Put a director in the composite.
> I think the problem here is that when SDF is trying to calculate the bala
> equations, it is not finding the connection. This is a problem with
> transparent CompositeActors.
> I verified that the error message appears in Ptolemy II 6.1.devel,
> 6.0.2 and 5.0.1, so this is not a new misfeature.
The error message about ports being disconnected was misleading (aka wrong).
However, there is no easy fix for this as a transparent composite actor
has nothing to fire during initialize(), so there is no easy way to detect this.
We could modify PortParameter so that it can only be placed in a composite
that has a director, but then if the director was removed after the
PortParameter was instantianted, we would not have any way of detecting this.
Also, if the MoML created the PortParameter before the director was added,
then there would be an error.
I modified SDFScheduler so that if actors are not connected, it looks for
transparent composite actors that have PortParameters and lists the PortParameters. This is a hack, but better than nothing. To get this
change, update to the most recent version of ptolemy by using the
magic ant command in the build system that builds from the ptII head.
The default "ant update" will not build from the ptII head.
I'm marking this as WONTFIX because we are not likely to ever fix this.
If someone disagrees, feel free to reopen and hopefully give a lower priority.