Aspen Properties initialization fails when logged

[michelpons]

I am conducting an interoperability test between an Aspen Properties Property Package and gPROMS. Aspen Properties is at version 7.1 CP1 and gPROMS at version 3.2.0, so they are at their current latest versions.

The test fails and COLTT is brought in to investigate. By using COLTT v1.07 on Aspen Properties Thermo System, I get a log file explaining what happens. With COLTT v1.08.02 enabled on Aspen Properties Thermo System, the run stops early on with initialization failing for the Thermo System.

[michelpons]

gPROMS console view when COLTT v1.07 is enabled

[michelpons]

Log file obtained with COLTT 1.07 enabled on Aspen Properties

[michelpons]

gPROMS console view when COLTT v1.08.02 is enabled

[michelpons]

Log file obtained with COLTT 1.08.02 enabled on Aspen Properties

[michaelhalloran]

Michel,

Can you check what ATCOProperties.COPropertySystem.23.0 sets as the value of CapeVersion in the CapeDescription area of the registry? It's shown in the Component Detail area of the COLoggingController when the component is selected as well. COLTT expects the component to be registered twice if it supports both 1.1 and 1.0 and at 1.08 introduced a version check which relies on this and which happens immediately after the last line that appears in the 1.08.2 log file. I suspect the version check is failing. If that happens COLTT doesn't return either a logger or the component itself to the PME, in other words it looks to the PME as though construction has failed.

[michelpons]

Michael,

the CapeVersion is set to 1.0.0

I checked this in COLTT controller as well as in the Windows registry

[michaelhalloran]

Michel,

so that's the problem then, COLTT is looking for 1.0

You could test by changing the registry if you are willing to do that temporarily.

Do you remember why version checking was added? I think it was to determine the right logger to use for a component that implemented both 1.0 and 1.1 interfaces.

I think the logic needs to be changed. Either the first interface requested must determine which logger is created - although that's not foolproof either, for example what happens if the first interface requested is ICapeUtilities - or the loggers must be more adaptive, in other words create the logger needed for an interface only when the interface is requested and only if the PMC supports the interface.

A simpler short-term solution would be to check for alternatives of version number so 1.0 or 1.0.0 for a 1.0 PMC and 1.1 or 1.1.0 for a 1.1 PMC.

[michelpons]

Michael,

I created a topic on CAPE-OPEN forum about CapeVersion. Jasper confirmed there that CapeVersion is poorly documented in CAPE-OPEN specs. He pointed out though that by checking only the first two digits in CapeVersion, it would do. Is this feasible for COLTT?

I was also thinking of asking Aspentech to change the CapeVersion to 1.0 and to check for other PMCs as well so that a consistent approach is used.

[michaelhalloran]

Michel,

This should be fixed in the 1.08.3 build. I implemented the change suggested by Jasper. I tested using COFE and TEA and manually changed the CAPEVersion string to use both 1.1 and 1.1.0 but it needs testing with Aspen Properties.

I'm marking it as fixed, but can you please confirm?

[michelpons]

I have checked the issue with COLTT 1.08.3 (Build Oct 27, 2010). While enabling COLTT on Aspen Properties Thermo System, I have now a run that behaves as when COLTT is not enabled and that provides a log file explaining why the simulation fails. So the issue can be considered as fixed. I have attached the log file obtained with the new build of COLTT (gservercorba_103109_120427.log).

[michelpons]

Log file obtained with COLTT 1.08.3 (Build Oct 27, 2009)