Ticket #8 (closed defect: fixed)

Opened 11 years ago

Last modified 11 years ago

Aspen Properties initialization fails when logged

Reported by: michelpons Owned by: Michael Halloran
Priority: major Milestone: Refactoring
Component: COLoggers Version: 1.08.2
Keywords: Cc: michaelhalloran

Description

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.

Attachments

ConsoleCOLTT107.txt (9.9 KB) - added by michelpons 11 years ago.
gPROMS console view when COLTT v1.07 is enabled
gservercorba_091409_144120_v107.log (12.3 KB) - added by michelpons 11 years ago.
Log file obtained with COLTT 1.07 enabled on Aspen Properties
ConsoleCOLTT10802.txt (7.6 KB) - added by michelpons 11 years ago.
gPROMS console view when COLTT v1.08.02 is enabled
gservercorba_091409_150811v1.0802.log (880 bytes) - added by michelpons 11 years ago.
Log file obtained with COLTT 1.08.02 enabled on Aspen Properties
gservercorba_103109_120427.log (12.3 KB) - added by michelpons 11 years ago.
Log file obtained with COLTT 1.08.3 (Build Oct 27, 2009)

Change History

Changed 11 years ago by michelpons

gPROMS console view when COLTT v1.07 is enabled

Changed 11 years ago by michelpons

Log file obtained with COLTT 1.07 enabled on Aspen Properties

Changed 11 years ago by michelpons

gPROMS console view when COLTT v1.08.02 is enabled

Changed 11 years ago by michelpons

Log file obtained with COLTT 1.08.02 enabled on Aspen Properties

comment:1 Changed 11 years ago by 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.

comment:2 Changed 11 years ago by michelpons

Michael,

the CapeVersion is set to 1.0.0

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

comment:3 Changed 11 years ago by 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.

comment:4 Changed 11 years ago by 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.

comment:5 Changed 11 years ago by michaelhalloran

  • Status changed from new to closed
  • Resolution set to fixed

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?

comment:6 Changed 11 years ago by 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).

Changed 11 years ago by michelpons

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

comment:7 Changed 11 years ago by michelpons

  • Milestone set to Refactoring
Note: See TracTickets for help on using tickets.