Parameter Common interface - economic dimension
Posted: 30 May 2018, 13:14
The is considering updating the parameter dimensionality property array to include an element that represents economic units to allow PMCs and PME to communicate economic information such as equipment costs, installed costs, operating costs, material costs.
Currently, economic information can be passed between the PME and PMC using a real-valued parameter that provides neither information that the value represents economic data nor the currency used. Adding an economic element to the Parameter dimensionality array would explicitly bring economics and costing into the domain of CAPE-OPEN. A potential use of this capability would allow the PME to perform a cost analysis of a flowsheet with economic data provided by the unit operation PMCs. Another example was presented by at the where operating and capital cost were included in a report made by a Unit Operation supplied to a Flowsheet User. Clearly, without the ability to share economic information with other Flowsheet objects, the ability to perform economic analysis and optimization of a Flowsheet is reduced.
Question 1: Would you be interested in adding an economic dimension to the dimensionality of real-valued parameters?
Question 2: Does your PMC currently support the ability to provide/utilize economic data?
Question 2A: If not, would you be interested in adding this capability?
Question 3: Can your PME support parameters with an economic aspect to the dimensionality?
Question 3A: If not, would you be interested in adding this capability?
One issue that came up in the discussion is the unit of currency, i.e. US dollars ($), Euros (€), etc. There needs to be a mechanism to handle the potential for different currency units. It is noted that current operating systems include currency as part of the locality settings of the local machine, which could provide a default currency for the current machine. Other options considered include creation of a fictitious currency unit (e.g. CAPE_OPEN_BUCKS) that could be assigned an arbitrary value, or the Parameter Owner could include the currency unit as a registry value or a separate Option Parameter (input or output, depending on whether the PME or PMC decides the unit of measure of money).
Question 4: What approach would you take to the issue of currency unit, choose one:
• The PMC imposes the currency unit (e.g. through a registry value), and the PME performs currency conversions.
• The PME imposing the currency unit (e.g. through a PME simulation context named-value), and the PMC performs the currency conversions.
• Impose a standard currency unit (Euro, US Dollar, Japanese Yen, CAPE_OPEN_BUCKS, or company-imposed unit), and both PMC and PME may need to perform currency conversion.
• Other: (please describe)
Currently, economic information can be passed between the PME and PMC using a real-valued parameter that provides neither information that the value represents economic data nor the currency used. Adding an economic element to the Parameter dimensionality array would explicitly bring economics and costing into the domain of CAPE-OPEN. A potential use of this capability would allow the PME to perform a cost analysis of a flowsheet with economic data provided by the unit operation PMCs. Another example was presented by at the where operating and capital cost were included in a report made by a Unit Operation supplied to a Flowsheet User. Clearly, without the ability to share economic information with other Flowsheet objects, the ability to perform economic analysis and optimization of a Flowsheet is reduced.
Question 1: Would you be interested in adding an economic dimension to the dimensionality of real-valued parameters?
Question 2: Does your PMC currently support the ability to provide/utilize economic data?
Question 2A: If not, would you be interested in adding this capability?
Question 3: Can your PME support parameters with an economic aspect to the dimensionality?
Question 3A: If not, would you be interested in adding this capability?
One issue that came up in the discussion is the unit of currency, i.e. US dollars ($), Euros (€), etc. There needs to be a mechanism to handle the potential for different currency units. It is noted that current operating systems include currency as part of the locality settings of the local machine, which could provide a default currency for the current machine. Other options considered include creation of a fictitious currency unit (e.g. CAPE_OPEN_BUCKS) that could be assigned an arbitrary value, or the Parameter Owner could include the currency unit as a registry value or a separate Option Parameter (input or output, depending on whether the PME or PMC decides the unit of measure of money).
Question 4: What approach would you take to the issue of currency unit, choose one:
• The PMC imposes the currency unit (e.g. through a registry value), and the PME performs currency conversions.
• The PME imposing the currency unit (e.g. through a PME simulation context named-value), and the PMC performs the currency conversions.
• Impose a standard currency unit (Euro, US Dollar, Japanese Yen, CAPE_OPEN_BUCKS, or company-imposed unit), and both PMC and PME may need to perform currency conversion.
• Other: (please describe)