09-018 COLTT 1.08.2 behaves differently to 1.07 in UniSim case

[michaelhalloran]

I am starting with a case file of UniSim Design R390 where one inlet stream is defined and three outlet streams are drawn. The scenario is to select a VB6 CAPE-OPEN UO (made by TOTAL) and insert it in the flowsheet, connect it, edit it and run it.

With COLTT 1.07, I get to the same point as without COLTT 1.07 enabled on the VB UO. The case can’t be run because the UO can’t be validated since the mixture molecularweight property is missing from the UniSim Design UO. You will find the file Screenshots_v107.doc showing the point I can reach and unisimdesign_082609_212727_v107.log as the log file obtained.

With COLTT 1.08.02 I can’t get so far. The UO does not load in UniSim Design when logged. You will find attached Screenshots_v10802.doc showing what happens as error message and unisimdesign_082709_075015_v10802.log as the log file obtained.

When I say attached, I will post the files as an archive on yousendit.com to ensure you can get access to these.

I am numbering this issue as COLTT09-018. I don’t know if the latest modifications committed by SHMA on COLTT will lead to a different behaviour. There is a need to know.

[michaelhalloran]

Michel, Is this using the version of 1.08.2 which has the fix for 09-015 that Ahsan created? If not, it looks like it could be the same problem.

[michelpons]

It is difficult for me to use the \"modified\" COLTT 1.08.02 on this case. The case is set in a different Virtual Machine from the one used for COLTT 09-015. In order to avoid conflicts between PMEs and PMCs, each PME is installed in a different VM at first. Then I install PMCs as needed and when a problem occurs with COLTT, the VM is copied and and kept aside. It is why I need an installer for the modified version or a way to build an installer from whatever version is in the virtual machine dedicated to COLTT09-015. Installing UniSim Design in the COLTT09-015 VM is close to impossible since the size of the virtual machine is not configured as to host two large PMEs.

[michelpons]

I have re-tested the combination with COLTT 1.08.03 (build Oct 19, 2009). I still find the same behaviour as with COLTT 1.08.02, i.e. the UO does not load up in UniSim Design when selected: UniSim Design crashes at that point. I have attached the log file obtained which logs successful communication till the point it stops.

[michelpons]

Log file obtained with COLTT 1.08.03 (Build Oct 19)

[michaelhalloran]

Michel,

Can you forward me the VB UO so that I can test it in COFE? The good news is that the log shows much more happening than the original 1.08.2 log, so I believe the persistence fixes in 1.08.3 have fixed the original problem. What you are seeing now is something different.

[michaelhalloran]

Removed an unnecessary call to get_ComponentName within the get_Specification method, which is close to where the latest log fails. Needs retesting in next build.

[michelpons]

I can't provide you with the UO which is proprietary to TOTAL. I would have to get a declassified version of the UO but I don't think I can get one easily since the developer is no more with TOTAL.

[michelpons]

I have tested the combination again with COLTT 1.08.3 Build Oct 27, 2009. After selecting the UO, I get a message about exceptions in COLTT and a debugger is proposed. I had to acknowledge the same kind of messages a number of times before getting tired of that and canceling the UniSim Design process. The test was made in a VM having Visual Studio installed. I got the log file (unisimdesign_103109_203736.log) attached. My understanding is that there is still some problem with this case.

[michelpons]

Log file obtained with COLTT 1.08.3 Build Oct 27, 2009

[michaelhalloran]

Michel,

Is this the VM where we were debugging? The new log is much more complete than the previous one so I think the problem I saw is now fixed. If you remember the exceptions that we saw were caused by the COLoggingController. Is that still the case? Do they happen of the Controller is open?

[michelpons]

This happens in the VM where the debugging was done within a remote session.

When leaving the COLTT controller open, there is no window popping up during the whole scenario. When COLTT controller is closed (by COLTT enabled on the UO), I get the first \"Just in time Visual Studio debugger\" window after selecting the UO and the Win32 exception which is not managed is said to be within COLoggingConroller.exe [2980]. Now is this meaningful in anyway? Does it show that something is fooling up or is it normal? I can't tell. I may be able to try COLTT 1.08.3 Build Oct 27, 2009 in a machine without Visual Studio and on the same combination.

[michelpons]

I have tested the case in a VM without Visual Studio. The behavior seems clean to me: there is no error window popping up even if the COLTT Controller is not open. The scenario goes to the point where the UO is not valid since Molecular weight is missing as a property on the UniSim Design MO.

So I believe the defect is indeed resolved. Whatever happens in the VM used for debugging is no issue for any end-user.