Terminate not appearing at first level in Viewer

[michelpons]

I am using PRO/II 9.2 alpha version provided by ANSYS and I have plugged in the CAPE-OPEN VB6 PPM under version 1.0.0.3. I have defined a single stream that I am flashing at T and P. The case file exists already and the simulation logged is just a reloading and a run, then existing PRO/II. I am surprised by the fact that the Terminate calls on the PPM and on the PP do not appear at the first level but are embedded apparently further so that one needs to open up some method calls in order to have them appear. I would rather think that such calls should be at the same level of display at the Initialize calls. I am using COLTT 2.1 Build Aug 5, 2012.

[michelpons]

Log file obtained with COLTT 2.1 Build aug 5, 2012

[michelpons]

I think it boils down to the return from the call to CheckEquilibriumSpec not appearing in the log.

[michelpons]

I have set up a case in Aspen Hysys 7.3 that is making use of the same PPM. During its initialization process, Aspen Hysys calls CheckEquilibriumSpec on the Property Package and CheckEquilibriumSpec returns \"True\" for \"isSupported\". The difference is that in Aspen Hysys the CompoundID argument is listed as the last input argument for CheckEquilibriumSpec while this argument does not appear in the log made with PRO/II 9.2. In the Aspen Hysys case, the CompoundId argument is at \"NULL3 for both specifications, i.e. for temperature and pressure. Why COLTT is unable to report values for CompoundId?
Since I need to assess quickly how the 1.1 thermo socket in PRO/II 9.2 is working, I am moving the issue to critical.

[michaelhalloran]

Michel, can you attach the Hysys log, the PRO/II case and the Hysys case?

COLTT does not report compoundID if the PME does not define it. In this case it looks like Hysys creates an entry for CompoundID in the specification array but passes NULL as the value whereas PRO/II does not create the entry for CompoundID in the specification array. COLTT could be changed to report the fact that the specification array is only 3 elements long where 4 are expected. What does the code in the VB PPM do if the specification array is only 3 elements long? The fact that the return statement is missing from the log suggests that some sort of exception has been raised in the PPM which COLTT was not able to catch.

[michelpons]

I got feedback from PRO/II R&D: \"According to the CAPE-OPEN Thermo v1.1 specification, the compound identifier is optional and hence we are not included in the argument list.\". So the difference of behavior between PRO/II and Hysys comes from the fact that PRO/II did not use the optional argument while Hysys did. This is right from a specification point of view but something happens (I can't say it happens because of COLTT enabled on the VB6 PPM).

I will try to get to you the installer for the PRO/II 9.2 alpha version which is the first version of PRO/II with a 1.1 Thermo socket (half a giga ...). And I will send you the installer for the binaries and source code for the VB6 PPM through appropriate means. You should be able to tell what the PPM is doing. If an exception is raised by the PPM, it should somehow be returned and appearing in the log.

[michelpons]

In both PRO/II and Hysys, I am starting from scratch so there is no case file to start from.

In Hysys I don't go even to the definition of a stream, just defining the PP to be used till the end of the initialization process for such a PP. It gives the log file I am attaching now which shows that CheckEquilibriumSpec returns each time it is called.

[michelpons]

Log file obtained in Aspen Hysys with COLTT 2.1 Build Aug 5, 2012

[michaelhalloran]

This is what PROII 9.2 passes for the flash specification in the call to CheckEquilibriumSpec as displayed by the debugger in a COLTT session:

safearray safearray of BSTR = [3]
(0x025097d4 \"temperature\",0x00000000 <Bad Ptr>,0x02509824 \"Overall\") tagSAFEARRAY *
+ [0] 0x025097d4 \"temperature\" wchar_t *
+ [1] 0x00000000 <Bad Ptr> wchar_t *
+ [2] 0x02509824 \"Overall\" wchar_t *

I've uploaded proii_081812_224817.log which shows Terminate at the correct level and the error returned from the VB Package. In fact it is a Windows error and has the description \"Out of String Space\". This log was obtained with the setting: COLTT.AlwaysLogPMCErrors=true
Even without this setting the second log uploaded proii_081812_223305.log shows the error being caught and Terminate at the right level.
So I can't reproduce the original problem on my machine, but the explanation is that PROII is passing a null ptr as the value of \"basis\" and the VB code fails when it tests whether the string is equal to \"\". Note that the CPP version succeeds because it tests for length of the string rather than equality to the empty string.

Either PROII shouls actually allocate a string or the VB should implement a different test. The CAPE-OPEN standard should define whether 0x00000000 is a valid value for a CAPE-OPEN string or not.

[michaelhalloran]

PRO/II with VB6 PPM showing Terminate correctly

[michaelhalloran]

PRO/II with VB6 PPM with COLTT error logging turned off showing Terminate correctly

[michelpons]

Thank you for the analysis. SimSci-Esscor R&D has been informed of your findings. The M&T SIG within CO-LaN has been asked to comment about the NULL pointer for a BSTR string.

I however wonder why the issue was not reproducible on your machine. SimSci R&D was not able either to reproduce the issue.

I gather there is nothing to be changed in COLTT to eliminate the behavior I observed on my machine. If this is indeed the case, the ticket may be closed.

[michelpons]

The issue was with one of the strings used as arguments which was not properly allocated. It is considered useful to add systematic checking of BSTR arguments through the following code:

check value
if (val)

{if (SysStringLen(val)!=wcslen(val))

{not a valid BSTR

LogError(\"Not a valid BSTR value\");

}

}