Custom Query (122 matches)
Results (94 - 96 of 122)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#144 | fixed | Argument from CopyFromMaterial | Michael Halloran | michelpons |
Description |
I am starting from a case file out of PRO/II 9.2 in which three material streams have been drawn and two defined with flow, composition, pressure and temperature. The CPP Ideal Thermo PPM and its nC6nC8 PP are used. The scenario calls for inserting the CPP Mixer/Splitter Example in the flowsheet, access its CAPE-OPEN settings, change the heat input to 1, then connect the ports to material streams and run the simulation. It gives the log attached. At the beginning of the Calculate method, the UO calls CopyFromMaterial onto a Material Object. The Material Object is mentioned as Anonymous. Within this call, it is logged that COLTT accesses the get_ComponentName method of the ICapeIdentification interface of an Anonymous MO: S1 is returned. Then the UO goes on by getting the present phases on a MO still mentioned as Anonymous. The CopyFromMaterial method has one argument, source. I think it would be wise somehow to mention the pointer value to the source MO. Further information could be displayed if indeed the get_ComponentName call succeeds like it is succeeding here. |
|||
#150 | fixed | Check if names of duplicated MOs are retrieved | Michael Halloran | michelpons |
Description |
I am opening up in Aspen Plus v7.3.2 a case file that makes use of Aspen Plus embedded thermo and of the VB6 Mixer Splitter example used as a splitter. I run the case and analyze the log file obtained with COLTT 2.1 Build 246. Within the Calculate call, there is a call to Duplicate the MO named as 1: MaterialObject <1> : Call to Duplicate MaterialObject Duplicate returns clone: 013A43B0 MaterialObject <1> : Return from Duplicate - Succeeded Once this is done I presume that most subsequent CalcProp and CalcEquilibrium calls are made on the duplicated MO. However the following is logged: MaterialObject <1> : Call to CalcProp requesting:
MaterialObject <1> : Return from CalcProp - Succeeded I wonder if COLTT has really updated the name of the MO, or if the duplicated MO has the same component_Name as the original MO. I can't see any call to get_componentName on the ICapeIdentification interface carried by the duplicated MO. Would be necessary to know what is going on. If the duplicated MO is given the same name as the original MO by the PME, it may induce some recommendation to developers to avoid that situation. |
|||
#156 | fixed | Worflow of new Controller version | Michael Halloran | michelpons |
Description |
Build 263 is used: when opening up Controller and selecting a given component, the \"Enable Logging\" box is appearing as non-ticked. The \"Call CAPE-OPEN error interfaces if errors are raised\" box and \"Log Reference counts\" box are ticked and greyed out. Then I tick the \"Enable Logging\" box. The \"Call CAPE-OPEN error interfaces if errors are raised\" box and \"Log Reference counts\" box remain ticked and are now ungreyed. Next I untick the \"Enable Logging\" box. The \"Call CAPE-OPEN error interfaces if errors are raised\" box and \"Log Reference counts\" box have then greyed out and unticked. I close the COLTT controller and then enters it again. When going to the same component as before, the \"Enable Logging\" box is unticked while The \"Call CAPE-OPEN error interfaces if errors are raised\" box and \"Log Reference counts\" box are ticked and greyed out. I would think that ticking or unticking the \"Enable Logging\" box should not alter the two other boxes. Since by default these two boxes are ticked but greyed out, it means that they are partially independent from the \"Enable Logging\" box. Anyway they will be \"active\" only when a component is logged. Now I wonder if really the selection for these boxes is per component or rather is it for the entire set of components to be logged. I don't exactly how the implementation is done. If reference counting and error interface calls are not component dependent, the corresponding boxes should appear elsewhere than within a component detail. |