Y2023-28: Specification of tests

Thermo SIG examined the logic of a Test verifying the functionality of method CalcAndGetLnPhi of interface ICapeThermoPropertyRoutine.

Method CalcAndGetLnPhi is one of a kind in the CAPE-OPEN standard since, contrary to most if not all other methods, it does not rely on the Material Object for its inputs (conditions of calculation) and its outputs (results).

The general approach for the Test is that it loops on the set of conditions defined for single-phase Physical Properties, and checks for consistency between the results returned by CalcAndGetLnPhi and the results provided by CalcSinglePhaseProp, when this method is applied to the same Physical Properties as the ones delivered by CalcAndGetLnPhi. The Test also verifies that CalcAndGetLnPhi identifies the Compounds on the Material Object.

The Test is sequenced in such a way that it exercises CalcAndGetLnPhi separately for the calculation of natural logarithm of fugacity coefficients, its derivatives with respect to temperature, pressure and mole numbers. Then the Test exercises combinations of these calculations to check behaviour and results are consistent.

Reviewing the logic of the Test raised several questions, pertaining mostly to the notes on CalcAndGetLnPhi in the Thermodynamic and Physical Properties interface specification.

The interface specification imposes that “The state of the Material Object is not affected by calling this method” when referring to method CalcAndGetLnPhi.

Thermo SIG discussed if the state should not be touched during the execution of CalcAndGetLnPhi or if the state should be the same before and after the execution of CalcAndGetLnPhi. For example, it was envisioned that, during the calculation of fugacity coefficients, the Property Package may want to store intermediate Physical Property calculations on the Material Object. Thermos SIG ruled that this possibility of storing intermediate results is denied to the Property Package on interfaces implemented on the Material Object. However, this rule must not prevent the Property Package to set custom values using the ICapeThermoCustomData interface possibly implemented on the Material Object. Therefore, Thermo SIG decided that the Test should check if any method capable of setting values, or information, on the Material Object is exercized during the execution of CalcAndGetLnPhi, with the exception of methods of ICapeThermoCustomData interface.

The interface specification states that “The compounds in the Material Object must have been identified and the number of mole fraction values supplied in the moleNumbers argument must be equal to the number of Compounds in the Material Object.”

Thermo SIG considered the case of a Property Package using Ideal Gas law as its thermodynamic model. Then the Property Package will return systematically zero for all natural logarithms of fugacity coefficients whatever the Compound, while derivatives with respect to temperature, pressure and mole numbers will be null as well. It seemed unnecessary then for the Property Package to have CalcAndGetLnPhi identifying the compounds supported by the Material Object. Nevertheless, Thermo SIG decided to apply the requirement in its generality. Therefore, the Test is checking if ICapeThermoCompounds::GetCompoundList is called either during the execution of ICapeThermoMaterialContext::SetMaterial or during the execution of CalcAndGetLnPhi. Still Thermo SIG would like to consider further the possibiity to relax somewhat the requirement expressed in the interface specification.

The interface specification for CalcAndGetLnPhi enables to combine the request for calculation of different properties. It is unclear, from the current wording of the interface specification, if, when individual property calculations are possible, any combination of such calculation requests must be honored by the Property Package. The current logic of the Test enforces that once a type of calculation works, it should work in any combination with other working calculations. Still, for the sake of rapidly developing Property Packages, calculation of each Physical Property (logfugacityCoefficient, logFugacityCoefficient.Dtemperature, logFugacityCoefficient.Dpressure, and logFugacityCoefficient.Dmoles) could be considered as completely independent and not able to run together. So Thermo SIG felt that, at best, the interface specification should clearly state what is possible or not.

Thermo SIG felt as possibly too strong the following requirement stated in the interface specification: “The values returned by this method should be identical to the equivalent quantities returned by the CalcSinglePhaseProp method with the same input information set on the Material Object.”. This requirement may have as consequence that a Property Package that can return the logarithm of fugacity coefficients at given conditions should have the Physical Property logFugacityCoefficient declared as supported through the list of identifiers returned by GetSinglePhasePropList. At best the interface specification should be more explicit on the matter. The Test is devised so far in such a way that, should a Physical Property be declared as not supported by the Property Package, but calculable through CalcAndGetLnPhi, the component-under-test is considered as compliant with the interface specification. May be revised at a subsequent stage.

Among the other points discussed is the need and possibility to check if output arguments are populated with anything when CalcAndGetLnPhi is exercised with the request that no calculation takes place. A related point is to figure out if CalcAndGetLnPhi, within the arrangement of the Test, should be allowed to raise an exception when no calculation is requested from CalcAndGetLnPhi. The current logic of the Test considers as non-compliant a Component-under-Test for which such a request of no calculation raises an exception.