Warn if ct and modal are combined or if continuous and fsm are combined

Edward wrote:

I agree!

Edward

Thomas Huining Feng wrote:

Hi Edward and Christopher,

This way of checking compatibility is a bit ad hoc. It depends on a particular method implemented in a director.

A better solution may be to implement a common interface for specifying compatibility and a checker that checks compatibility with information provided via that interface. (Can this be done with an ontology lattice?)

Some allowable types of composition has been discussed in this paper: Antoon Goderis, Christopher Brooks, lkay Altintas, Edward A. Lee, "Composing Different Models of Computation in Ptolemy II and Kepler"

Allowable composition with Ptera is discussed in my thesis.

EmbeddedPtidesDirector can only be contained within DE.

FSM is used only when CT is in the hierarchy and modal is not.

Etc.

It seems it's better to summarize all this information in an easy-to-access place.

Edward A. Lee wrote:
ContinuousDirector has some code in it already that almost does the right thing:
private ContinuousDirector _enclosingContinuousDirector() {
    if (_enclosingContinuousDirectorVersion != _workspace.getVersion()) {
        // Update the cache.
        _enclosingContinuousDirector = null;
        NamedObj container = getContainer().getContainer();
        while (container != null) {
            if (container instanceof Actor) {
                Director director = ((Actor) container).getDirector();
                if (director instanceof ContinuousDirector) {
                    _enclosingContinuousDirector = (ContinuousDirector) director;
                    break;
                }
                if (!(director instanceof QuasiTransparentDirector)) {
                    break;
                }
            }
            container = container.getContainer();
        }
        _enclosingContinuousDirectorVersion = _workspace.getVersion();
    }
    return _enclosingContinuousDirector;
}
Notice the marker interface QuasiTransparentDirector to ensure that we see an enclosing director even if separated by an arbitrary number of levels of modal model.

What about doing a string comparison of the class name to avoid the dependency?

I think the check needs to be done at run time (in preinitialize, say), but it would possibly be useful to also issue a warning during construction. It should be just a warning, however, or it will prevent being able to read MoML files containing the error.

Edward

Christopher Brooks wrote:

Hi Edward, I was thinking about how we would warn if domains.ct was used with domains.modal or if domains.continuous was used with domains.fsm.

The naive solution would be to have the domains.modal constructor check for directors that are instances of domains.ct.kernel.CTDirector. However, this would add a dependency between domains.modal and ct.

An alternative would be to add a marker interface to ptolemy.actor and have domains.ct.kernel.CTDirector implement it.

We would need to do something similar for continuous and domains.fsm.

I think we need to traverse check the directors in the containers of domains.modal and check each parent director.

We might also want to check parent directors in ct.kernel.CTDirector and continous.kernel.ContinuousDirector.

I think we should do this at instantiation time instead of runtime to avoid people building incorrect models. However, it might be safer to try to detect this at runtime so that people can recreate incorrect models with the correct director.

Thoughts?

_Christopher

Edward A. Lee wrote:

I've checked in a fix.

The problem is that you changed the demo to use domains.modal instead of domains.fsm, but the demo uses CT.

Models that use CT should continue to use FSM. CT can probably be made to work with modal, but I don't have the energy or time to make this happen.

Ideally, we would catch this error and throw a friendlier exception.

Edward

Thomas Huining Feng wrote:

Hi,

As I tested the GT demos, I found this new exception in BouncingBallX2 (in ptolemy/actor/gt/demo/BouncingBallX2). I have no idea what this means or when it started happen.

ptolemy.actor.sched.NotSchedulableException: Signal type conflict: ...Ball Model.yPosition (of type DISCRETE) and ...PeriodicSampler.input (of type CONTINUOUS)). Perhaps the connection has sequence semantics? in ...Ball Model.yPosition, ...PeriodicSampler.input at ptolemy.domains.ct.kernel.CTScheduler$SignalTypeMap.propagateType(CTScheduler.java:1363) at ptolemy.domains.ct.kernel.CTScheduler._getSchedule(CTScheduler.java:584) at ptolemy.actor.sched.Scheduler.getSchedule(Scheduler.java:188) at ptolemy.domains.ct.kernel.CTMultiSolverDirector.initialize(CTMultiSolverDirector.java:541) at ptolemy.domains.ct.kernel.CTMixedSignalDirector.initialize(CTMixedSignalDirector.java:192) at ptolemy.actor.CompositeActor.initialize(CompositeActor.java:719) at ptolemy.actor.Director.initialize(Director.java:731) at ptolemy.actor.Director.initialize(Director.java:704) at ptolemy.actor.CompositeActor.initialize(CompositeActor.java:719) at ptolemy.actor.Manager.initialize(Manager.java:615) at ptolemy.actor.Manager.execute(Manager.java:338) at ptolemy.actor.gt.ModelExecutor.fire(ModelExecutor.java:107) at ptolemy.actor.process.ProcessThread.run(ProcessThread.java:217)

icyphy / ptII

Warn if ct and modal are combined or if continuous and fsm are combined #186