Reported by michelpons, 15 years ago.

A defect had been raised a while ago with SimSci-Esscor about the fact that InitNew was not called by PRO/II on a a new CAPE-OPEN UO being inserted in a flowsheet. According to SimSci-Esscor secondary support, the bug LFPE#25122 (InitNew not called) got fixed and working fine. However the log I can make of a COUSCOUS UO in PRO/II 8.3 does not show InitNew being called (see proii_090909_194007.log). SimSci-Esscor thinks that COLLT is not reporting InitNew call when the persistence type is IPersistPropertyBag.

They have tested the behavior with their internal CAPE-OPEN test units (COSESPersistB100.dll, COSESPersistC100.dll and COSESPersistD100.dll in zipped archive). The COLTT log file (proiid_PKM.log) shows that InitNew is called for persistence types IPersistStreamInit and IPersistStorage (they made their run with COLTT 1.07). However, the COLTT log file does not show the call to InitNew when the persistence type is IPersistPropertyBag. SimSci-Esscor has debugged the code and noticed that InitNew is called for IPersistPropertyBag also. So there is a good chance that COLTT has not implemented IPersistPropertyBag and that leads to an improper report on InitNew being called.

Reported by michelpons, 13 years ago.

When analyzing logs obtained with COLTT 1.08.5 with two different PMEs and the same PMC (the CPP Mixer Splitter example), I have noticed that within the Calculate method, the Duplicate method is called twice (because there are two feeds to the UO) and each time the pointer returned appears as the same. This is worrying me because in fact the previous MO is not released before a new duplicate is done according to the following excerpt of the CPP Mixer Splitter code:

bool Duplicate(Material &m,wstring &error) {ATLASSERT(materialObject); class should be instanciated properly create a new material object MaterialObjectWrapper *MO=materialObject->Duplicate(error); <------- NEW ONE IS OBTAINED if (!MO) return false ; fail clean up old MO in m if (m.materialObject) m.materialObject->Release(); <------- OLD ONE IS RELEASED set new m.materialObject=MO; ok return true ;

}

So while this has no consequence really for the CPP Mixer Splitter it is of interest to know if the pointer mentioned in the log is the real pointer or one pertaining to the CO logger. Could this be assessed?

Reported by michelpons, 13 years ago.

I am using PRO/II 9.1, together with a TEA Property Package and the COUSCOUS Mixer. The TEA Thermo System and the COUSCOUS Mixer are both logged with COLTT. I start from a case file where the Material Streams have been defined with the CEA C1_C2 (EOS) as Property Package. I am adding the COUSCOUS Mixer, connecting the two inlets and the outlet ports to streams and then I launch the Calculation which ends up in error.

The log I get in the Viewer shows that Calculate is not as the same level as Validate which is odd. Going to the raw file I see that there is no return for the get_NamedValueList call.

When logging is not enabled on either components, the calculation does not end up in error.

Attached are the log file obtained and the screenshot of the Viewer as obtained.