Aspen Hysys crashes when using logged Aspen Properties PP

[michelpons]

I am using a simple Aspen Properties PP in Aspen Hysys. Without COLTT enabled on Aspen Properties Therrmo System, I see no problem. When enabling COLTT on Aspen Properties Thermo System, I have a crash just after selecting the PP from Aspen Properties Thermo System. In the attached log, I see:

MaterialObject <Anonymous> : Call to SetProp :

Property
PhaseFraction Vapor mole (null) -179769313486231570000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.000000000

which may be wrong but does not cause a crash without COLTT.

[michelpons]

Log file obtained with Aspen Properties PP in Aspen Hysys

[michelpons]

As per your communication dated May 30, 2011: \"this was caused by a buffer overflow due to the constant DBL_MAX being passed as a value for a property. DBL_MAX is 1.79769313E+308. AT say this is CapeDoubleEmpty but the standard does not define such a value. It does reference CapeDoubleUndefined as 2^{31 in the .idl but it is commented out. Anyway, the logger should be able to deal with this now. It should print \"1.79769313E+308 (undefined double value)\" where this value is passed through setProp or getProp. COLTT doesn't treat it as a warning or an error in this build. I've only been able to test this in a small test program outside COLTT but I believe COLTT should not fail like it did before but it needs testing with A+. What do you think, should passing this value be considered an error or a warning? \". I have installed the COLTT build of May 30, 2011. Then I have run a scenario involving an Aspen Properties 24.0 (i.e. v7.2) Thermo System in HTRI Xist v6.0. This scenario showed a SetProp on PhaseFraction property for solid phase in a CaclEquilibrium call with a CapeDoubleUndefined value that made Xist crash when the Thrmo System was logged. With the new build, the run goes to its end and the log shows mention that a CapeDoubleUndefined was set. So the new build resolves the issue.
I can't say yet if returning CapeDoubleEmpty should be mentioned as an error or just as a warning. Need to discuss this with Methods & Tools SIG.}

[michelpons]

Zipped log file obtained with COLTT Build May 30, 2011