[kepler-dev] Type error with NondeterministicMerge under Kepler

[Dan Higgins]

Hi Norbert,
    I have been examining your problem. Yes, the Ptolemy workflow works 
for me under Kepler and the Kepler version does not. But how was the 
Kepler version built? I can save the Ptolemy wf in Kepler and the port 
types are not set (i.e. the wf works). There is no NondeterministicMerge 
actor in the Kepler actor list, so I had to use the menu 
'Tools/Instantiate Component' to get it to appear in Kepler. Still no 
problem with the port types!
    Was the NondeterministicMerge actor somehow added to Kepler's actor 
list?

Dan Higgins

-----

Norbert Podhorszki wrote:
> Hi,
> ,
> We have hit a type problem in Kepler with Bruce while playing with the 
> NondeterministicMerge actor and then found an interesting and annoying 
> difference between the type checking in Kepler and Ptolemy. Now we 
> know how to solve the problem by specifying the types manually but 
> still we wonder if this is a bug or just a side-effect how Kepler 
> stores actors in its xml.
>
> The model
> =========
> In the attached examples, there is a simple pipeline
>
>    Record Assembler  ---  Nondet.Merge  ---  Record Disassembler
>
> i.e. we want to push record tokens through the model.
> The Ptolemy version (built under Ptolemy) works as expected, even 
> under Kepler. The Kepler version, however, does not run because we get 
> an error from the type checker:
>
>     ptolemy.kernel.util.InternalErrorException: Type resolution failed 
> because
>     of an error during type inference
>        in .NondetMerge_TypeError_Kepler
>     Because:
>     Invalid type for input port
>        in .NondetMerge_TypeError_Kepler.Record Disassembler
>
> The difference
> ==============
> Replacing the NondeterministicMerge entity manually in the Kepler 
> workflow xml with the entity in the Ptolemy model (see 
> NondetMerge_TypeError_KP.xml), the error disappears.
>
> The difference between the two entities is that while Ptolemy only 
> declares the class
>     <entity name="NondeterministicMerge" 
> class="ptolemy.domains.pn.kernel.NondeterministicMerge">
>         <property name="_location" 
> class="ptolemy.kernel.util.Location" value="[350.0, 160.0]">
>         </property>
>     </entity>
>
> Kepler enumerates the ports and their types as well, which, in the 
> case of NondeterministicMerge are 'general'.
>     <entity name="NondeterministicMerge" 
> class="ptolemy.domains.pn.kernel.NondeterministicMerge">
>         <property name="_location" 
> class="ptolemy.kernel.util.Location" value="[350.0, 160.0]">
>         </property>
>         <port name="input" class="ptolemy.actor.TypedIOPort">
>             <property name="input"/>
>             <property name="multiport"/>
>             <property name="_type" class="ptolemy.actor.TypeAttribute" 
> value="general">
>             </property>
>         </port>
>         <port name="output" class="ptolemy.actor.TypedIOPort">
>             <property name="output"/>
>             <property name="_type" class="ptolemy.actor.TypeAttribute" 
> value="general">
>             </property>
>         </port>
>     </entity>
>
> The manual solution
> ===================
> AFAIK, the type checker then will not climb down from the top 
> 'general' to find that always just RecordType tokens will be emitted. 
> If we set the types of the input and output ports of the actor to our 
> specific record type in the GUI, then it works again.
>
> Then why do we complain?
> ========================
> First of all we wonder if this is necessary to be this way in Kepler.
> Second, how many actors may be there that can bring such a surprise to 
> the developer.
>
> Third, no one should wonder that the beginner developer is completely 
> lost since he does not understand the Ptolemy error message, and 
> actually he made nothing wrong, so after crawling through the hopeless 
> route down to hell, desperately looks for advise from an experienced 
> developer, who also has no idea. Lots of trials, small test examples 
> and changing from Kepler to Ptolemy for counter-testing reveals what's 
> wrong (since the error message does not reveal it) and finally the 
> solution come. Since the beginner developer committed nothing wrong, 
> it would be good not to get into such situation.
>
> Oh and yes, I know that he should not go with the nondet merge at all 
> and I will help him to create a DDF solution for his problem. 
> Eventually. ;-)
>
> Best regards
> Norbert
>
>
>      Norbert Podhorszki
>    ------------------------------------
>      University of California, Davis
>      Department of Computer Science
>      1 Shields Ave, 2236 Kemper Hall
>      Davis, CA 95616
>      (530) 752-5076
>      pnorbert at cs.ucdavis.edu
>      ----------------------------------
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev