Ticket #164 (assigned enhancement)
Need to indicate better argument type
Reported by: | michelpons | Owned by: | michaelhalloran |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | COLoggers | Version: | 2.1 |
Keywords: | Cc: | michaelhalloran |
Description
In Aspen Hysys 7.2 I have made a 1st run with a Simulis Thermodynamics PP. Examining the log I see that all calls to CheckEquilibriumSpec return an exception. Next I have run a TEA Property Package, also through CAPE-OPEN interfaces 1.1, in Aspen Hysys 7.2. There the CheckEquilibriumSpec calls return isTrue. By discussing with ProSim support, I know that the Simulis Thermodynamics PP should also return isTrue for the specifications proposed. The calls made by Aspen Hysys are:
PropertyPackage <Anonymous> : Call to CheckEquilibriumSpec
CheckEquilibriumSpec takes input arguments:
Specification1 Specification2 Solution Type
Property temperature pressure Unspecified
Basis (null) (null)
Phase Overall Overall
CompoundId (null) (null)
According to a recent Errata document on Thermo 1.1, it is advised to check for both NULL and an empty string when testing for UNDEFINED if COM is used. It appears the test in Simulis Thermodynamics does not go well. It is then necessary to know exactly what is passed by Aspen Hysys to Simulis Thermodynamics. Would it be possible to catch the data type used in the communication for each argument parts?
Attachments
Change History
Changed 11 years ago by michelpons
- Attachment hysys_093013_115049_Simulis.zip added
Changed 11 years ago by michelpons
- Attachment hysys_093013_122045_TEA.log added
Log file of TEA PP in Aspen Hysys 7.2
comment:1 Changed 11 years ago by michelpons
In the above example, when using COLTT build 275, I was able to force COLTT to call the error methods on Simulis Property Package in order to see what goes on within CheckEquilibriumSpec. It gives:
COLTT <NG-H-PPR78> : CAPE-OPEN error code returned is: ECapeInvalidArgumentHR
COLTT <NG-H-PPR78> : Getting error details from error ECapeRoot interface:
COLTT <NG-H-PPR78> : Call to get_Name
COLTT <NG-H-PPR78> : Name: CO Invalid Argument Exception
COLTT <NG-H-PPR78> : Return from get_Name - Succeeded
COLTT <NG-H-PPR78> : Getting error details from ECapeUser error interface:
COLTT <NG-H-PPR78> : Call to get_code
COLTT <NG-H-PPR78> : Code: 0
COLTT <NG-H-PPR78> : Return from get_code - Succeeded
COLTT <NG-H-PPR78> : Call to get_description
COLTT <NG-H-PPR78> : Description: The solutionType argument is unknown.
COLTT <NG-H-PPR78> : Return from get_description - Succeeded
COLTT <NG-H-PPR78> : Call to get_scope
COLTT <NG-H-PPR78> : Scope: CapeOpen::Thermo::PropertyPackage (1.1)
COLTT <NG-H-PPR78> : Return from get_scope - Succeeded
COLTT <NG-H-PPR78> : Call to get_interfaceName
COLTT <NG-H-PPR78> : Interface Name: ICapeThermoEquilibriumRoutine
COLTT <NG-H-PPR78> : Return from get_interfaceName - Succeeded
COLTT <NG-H-PPR78> : Call to get_operation
COLTT <NG-H-PPR78> : Operation: CheckEquilibriumSpec
COLTT <NG-H-PPR78> : Return from get_operation - Succeeded
COLTT <NG-H-PPR78> : Call to get_moreInfo
COLTT <NG-H-PPR78> : More Info: (null)
COLTT <NG-H-PPR78> : Return from get_moreInfo - Succeeded
PropertyPackage <NG-H-PPR78> : Error returned from CheckEquilibriumSpec - 0x80040506
Description says that the solutionType argument is unknown. The log says it is \"unspecified\". I am asked the value of solutionType. Would be great to know exactly what is passed, especially for special values such as unspecified which is not really defined in the spec.
comment:2 Changed 11 years ago by michaelhalloran
- Owner changed from Michael Halloran to michaelhalloran
- Status changed from new to assigned
Michel, you may remember a problem we had some time ago where the value of SolutionType was causing a crash? It was TRAC #140. As part of debugging that I modified the value passed to CheckEquilibriumSpec for solutionType to \"UNSPECIFIED\", well that change was still in the code. I have committed a change to pass solutionType properly which may help with this problem. Can you build commit 278 and check it?
comment:3 Changed 11 years ago by michelpons
I used Built 280 which incorporates commit 278. Applying COLTT in the same scenario as above, I am still faced with the same error returned by CheckEquilibriumSpec and the solutionType argument is still mentioned as unknown. No difference in the output. Displaying more basic information on the arguments may help understand what is going on.
comment:4 Changed 11 years ago by michelpons
I demonstrated with a simple case involving Simulis Thermodynamics (Sour Water model) and Aspen Hysys 7.2 that enabling COLTT on Simulis Thermodynamics PPM gives the following error messages in the control view of Aspen Hysys:
COMThermo Flash Failed OR Flash cannot be carried out at specified conditions. - HRESULT returned 80004005
COMThermo Flash Failed OR Flash cannot be carried out at specified conditions. - HRESULT returned 80004005
COMThermo Flash Failed OR Flash cannot be carried out at specified conditions. - HRESULT returned 80004005
While no such message appears when COLTT is not enabled on Simulis Thermodynamics PPM. These messages are directly linked to CheckEquilibriumSpec method returning an error highlighting the solutionType argument as an issue. Somehow COLTT is modifying the communication between Aspen Hysys and Simulis Thermodynamics.
Changed 11 years ago by michelpons
- Attachment hysys_101513_195458.log added
Log file Build 280 with simple Sour Water example
comment:5 Changed 11 years ago by michaelhalloran
Michel, in the case of Hysys and the Simulis Sour Water model what happens when COLTT is not used? Can you tell whether the CheckEquilibriumSpec call fails? Does the Flash itself fail? As far as I can see from the last log you've attached and the COLTT code, Hysys is passing a string with the value \"Unspecified\" as the solutionType argument into some of the CheckEquilibriumSpec calls. That string passes the test Jasper recommended to detect an invalid BSTR - that test is still in the COLTT code. Since build 280, COLTT is not modifying that argument, it only prints it out and then passes it through. Note that in other calls the value \"Normal\" is passed for solutionType but these calls also return errors. It would be helpful if simulis could include the value of solutionType that is unknown in the string returned from the get_description error call. Could you suggest that? Alternatively, if I had a licence to run it myself it would also help.
comment:6 Changed 11 years ago by michelpons
Michael,
when Simulis Thermodynamics is not logged, there is no error message within the Control View of Aspen Hysys. I analyze that as CheckEquilibriumSpec returning isTrue and Aspen Hysys proceeding with using the flash from Simulis Thermodynamics. Will see with ProSim what can be done to print the solutionType value and for the license.
Zipped log file of Simulis Thermodynamics in Aspen Hysys 7.2