IMPL (Advanced) Reference Manual for IML Logic/Logistics

18 pages
0 downs


Please download to get full document.

View again

of 18
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Download IMPL (Advanced) Reference Manual for IML Logic/Logistics
  • slide 1: I M P L Industrial Modeling Language IML "Advanced Reference Manual for Logic/Logistics" i n d u s t r I A L g o r i t h m s Version 1.0 July 2015 IAL-IMPL-IML-RMQL-1-0.docx Copyright and Property of Industrial Algorithms
  • slide 2: Introduction The IML Industrial Modeling Language file is our user readable import or input file to the IMPL modeling and solving platform which is implemented in IMPL Interfacer. IMPL is an acronym for Industrial Modeling and Programming Language provided by Industrial Algorithms LLC. The IML file allows the user to configure the necessary data to model and solve large-scale and complex industrial optimization problems IOPs such as planning scheduling control and data reconciliation and regression in either off or on-line environments. Please see our IML “Basic Reference Manual for Quantities” for a complete introduction on the basics of IML. This manual describes the configuration data necessary to model and solve IOP’s with logic and logistics quantity and logic variables and constraints i.e. setups startups switchovers shutdowns sequence-dependent switchovers etc. The symbol "" denotes an address index pointer or key the "" denotes an attribute item property characteristic or value and the prefix "s" stands for string name of which there are two other prefixes "r" and "i" for reals double precision and integers number respectively. String addresses and attributes are case sensitive and do not require any quotes where essentially any character is allowed including spaces except for "". Each address string field may have no more than 64 characters for it to be considered as unique and each attribute string field may have no more than 512 characters. Essentially multiple keys or “key-tuples” and multiple values or “value-tuples” for a single record is the fundamental data structure of IMPL where the values are restricted to be only one data type i.e. integer real or string. In other computer programming and algebraic modeling languages mixed or non-homogeneous data types called structs derived types tuples tuplelists etc. can be arbitrarily defined by the user but this is not available in IMPL. Constriction Data IMPL allows for the configuration of several diverse types of logic and logistics quantity and logic Constriction Data which comprise most of the configuration data for IOP’s involving logic and logistics
  • slide 3: details. These kinds of data deals with logistical aspects such as smoothing equaling using timing counting delaying switching etc. Flow- and holdup-smoothing minimizes the 1-norm and 2-norm deviations from the quantity in the previous time-period against the current time-period. sUnitsOperationrFlowSmoothing1_WeightrFlowSmoothing2_Weight UNITOPERATION FSWEIGHT 1 FSWEIGHT2 sUnitsOperationrFlowSmoothing1_WeightrFlowSmoothing2_Weight sUnitsOperationrHoldupSmoothing1_WeightrHoldupSmoothing2_Weight UNITOPERATION HSWEIGHT 1 HSWEIGHT2 sUnitsOperationrHoldupSmoothing1_WeightrHoldupSmoothing2_Weight sUnitsOperationsPortsStaterFlowSmoothing1_WeightrFlowSmoothing2_Weight UNITOPERATION PORTSTATEFSWEIGHT 1 FSWEIGHT2 sUnitsOperationsPortsStaterFlowSmoothing1_WeightrFlowSmoothing2_Weight Flow-equaling is similar to flow-smoothing except that equality constraints are created between the previous and current time-periods instead of minimizing the 1-norm and 2-norm deviation variables in the objective function. sUnitsOperationsFlowEqualing UNITOPERATIONON/OFF sUnitsOperationsFlowEqualing For the in and out port-states flow-equaling can be either or both “temporal” or “structural”. Temporal means that the flows over time on the port-state must be equal and structural means that the flow across all in/out port-states must be equal. The enumeration “on” is the same as temporal “off” is equivalent to “none” and “both” configures both the temporal and structural constrictions. sUnitsOperationsPortsStatesFlowEqualing UNITOPERATIONPORTSTATEON/OFF UNITOPERATIONPORTSTATETEMPORAL/STRUCTURAL/BOTH/NONE sUnitsOperationsPortsStatesFlowEqualing
  • slide 4: Both lower and upper bounds for multi-use restrictions are applied to noncontentious units planning whereas for contentious units scheduling the lower bound is assumed to be zero 0 and the upper is one 1. sUnitiMultiUse_LoweriMultiUse_Upper UNITLMULTIUSEUMULTIUSE sUnitiMultiUse_LoweriMultiUse_Upper Multi-use on inlet and outlet unit-operation-port-states in terms of how many in-flows and out-flows are allowed is configured using this frame. The lower bound multi-use constraint also includes the setup logic variable of its unit-operation to create it as a “semi-continuous” constraint. sUnitsOperationsPortsStateiMultiUse_LoweriMultiUse_Upper UNITOPERATIONPORTSTATELMULTIUSEUMULTIUSE sUnitsOperationsPortsStateiMultiUse_LoweriMultiUse_Upper The lower and upper number of startups for units and unit-operations forces IMPL to limit the number of startups over the future time-horizon. This is useful when a unit or unit-operation is only allowed to startup a certain number of times in the plan or schedule. sUnitiNumberStartups_LoweriNumberStartups_Upper UNIT LNUMSTARTUPSUNUMSTARTUPS sUnitiNumberStartups_LoweriNumberStartups_Upper sUnitsOperationiNumberStartups_LoweriNumberStartups_Upper UNITOPERATION LNUMSTARTUPSUNUMSTARTUPS sUnitsOperationiNumberStartups_LoweriNumberStartups_Upper The zero down-timing configuration forces IMPL not to shutdown the unit. This implies that at least unit-operation must be setup for the entire future time-horizon. sUnitsZeroDownTiming UNITON/OFF sUnitsZeroDownTiming The lower and upper up-timing configuration specifies in the same time-units as the time-horizons that the unit-operation if setup or started-up must be up or running for at least the lower up-timing configured and no greater than the upper up-timing.
  • slide 5: sUnitsOperationrUpTiming_LowerrUpTiming_Upper UNITOPERATIONLUPTIMEUUPTIME sUnitsOperationrUpTiming_LowerrUpTiming_Upper sUnitsOperationsPortsState sUnitsOperationsPortsStaterUpTiming_LowerrUpTiming_Upper UNITOPERATIONPORTSTATEUNIT2OPERATION2PORT2STATE2LUPTIMEUUPTIME sUnitsOperationsPortsState sUnitsOperationsPortsStaterUpTiming_LowerrUpTiming_Upper The lower and upper down-timing configuration specifies in the same time-units as the time-horizons that the unit or unit-operation if setdown or shutdown must be down or not running for at least the lower down-timing configured and no greater than the upper down-timing. sUnitrDownTiming_LowerrDownTiming_Upper UNITLDOWNTIMEUDOWNTIME sUnitrDownTiming_LowerrDownTiming_Upper sUnitsOperationrDownTiming_LowerrDownTiming_Upper UNITOPERATIONLDOWNTIMEUDOWNTIME sUnitsOperationrDownTiming_LowerrDownTiming_Upper sUnitsOperationsPortsState sUnitsOperationsPortsStaterDownTiming_LowerrDownTiming_Upper UNITOPERATIONPORTSTATEUNIT2OPERATION2PORT2STATE2LDOWNTIMEUDOWNTIME sUnitsOperationsPortsState sUnitsOperationsPortsStaterDownTiming_LowerrDownTiming_Upper The lower and upper fill-draw-delaying configuration specifies in the same time-units as the time- horizons that for the unit-operation of type pool if there is flow in to or the unit-operation is filling then any flow out of or drawing from the unit-operation must respect the lower and upper bounds. If the lower bound is zero 0 then this is useful for a pool to be standing-gauge or also known as a dead-tank i.e. as opposed to a live-tank. sUnitsOperationrFillDrawDelaying_LowerrFillDrawDelaying_Upper UNITOPERATIONLFILLDRAWDELAYUFILLDRAWDELAY sUnitsOperationrFillDrawDelaying_LowerrFillDrawDelaying_Upper
  • slide 6: The switching-when-empty and -full configuration specifies in the quantity-units that for the unit- operation of type pool that if the holdup is below the empty quantity or above the full quantity then the unit-operation can be switched. This is useful to model multi-purpose or multi-product non- dedicated tanks to allow their material service mode or operation to switch from one operation to another provided the empty or full quantities are respected. sUnitsOperationrSwitchingWhen_EmptyrSwitchingWhen_Full UNITOPERATIONSWITCHWHENEMPTYSWITCHWHENFULL sUnitsOperationrSwitchingWhen_EmptyrSwitchingWhen_Full The drawing-to-empty and filling-to-full constriction is similar to the switching-when-empty/full except that it is not related to switching-over to a different operation or material service. Instead it is relate to the mutually exclusive constriction that if the pool unit-operation is drawing then it must remain drawing until it satisfies the drawing-to-empty quantity specified below i.e. at or below the drawing-to- empty quantity. Conversely if it is filling then the pool unit-operation must continue to be filling or not filling but not drawing until it is at or above the filling-to-full quantity. This minimizes the fill-hold-draw dynamics for a pool and is a form of inventory or holdup logistical control. sUnitsOperationrDrawing_EmptyrFilling_Full UNITOPERATIONDRAWINGEMPTYFILLINGFULL sUnitsOperationrDrawing_EmptyrFilling_Full When this constriction is configured a drawing-filling logic variable is created for each pool unit- operation to model the mutexed drawing and filling logistics. The lower and upper flow-delaying configuration specifies in the same time-units as the time-horizons that for unit-operations of type batch-process and parcel their flows in and out of their unit-operation- port-states must respect these relative timings of when the unit-operation is started-up. The flow- delaying configurations are also useful to model semi-batch operations where there can be a delay between when material or other types of resources enter and leave the unit-operation. sUnitsOperationsPortsStaterFlowDelaying_LowerrFlowDelaying_Upper UNITOPERATIONPORTSTATELFLOWDELAY UFLOWDELAY sUnitsOperationsPortsStaterFlowDelaying_LowerrFlowDelaying_Upper
  • slide 7: Coupled with the flow-delaying for batch-process unit-operations IMPL allows relative-time yields within the batch-process up-timing to be configured i.e. within the flow-delaying lower and upper relative-times. This is useful to model relative-time-varying processes which have degrading declining and decaying yields for example although any exogenously configured yield pattern is acceptable monotonically increasing and/or decreasing. The initial-time final-time is similar to the start-time finish-time and begin-time end-time in the past and future absolute time-horizons respectively except that it is related to relative-time modeling i.e. within the unit-operation’s processing time. The initial-times must be in ascending or increasing order in the frame given that we use interpolation to disaggregate the yield profile over the relative-time of the processing-time. In addition each unit- operation’s yield entries records or features must be contiguously or consecutively configured and either constant linear or monotonic spline interpolation can be selected as the type of interpolation to use i.e. CIP LIP default SIP or KIP. sUnitsOperationsPortsStaterYieldDelaying_LowerrYieldDelaying_Upper rInitial_TimesType UNITOPERATIONPORTSTATELYIELD UYIELD INITIALINTERPTYPE sUnitsOperationsPortsStaterYieldDelaying_LowerrYieldDelaying_Upper rInitial_TimesType Consolidation Collection Data The Consolidation Data allows consolidations of unit-operations into collections such as unit-operation- groups which are useful for applying aggregation or consolidation constraints across several diverse unit-operations i.e. different units and different operations within the same group. Although not configurable at the moment there can also be unit-operation-port-state-groups and unit-operation- port-state-unit-operation-port-state-groups. sUnitsOperationsGroup UNITOPERATIONGROUP sUnitsOperationsGroup We also have unit-operation-operation-groups which are useful for sequence-dependent switchovers setups or changeovers when there is a constriction or restriction that some form of sequence- dependent switchover action activity or task must be taken between different operations in a different group on the same unit – see Compatibility Data.
  • slide 8: sUnitsOperationsOperationGroup UNITOPERATIONOGROUP sUnitsOperationsOperationGroup For unit-operation-groups it is possible to constrict or limit the phenomenon such as the group’s lower and upper setup across all unit-operations contained or consolidated within a group. Other phenomena such as flow holdup and other logic may also be configured. UOGSetup-sGrouprSetup_LowerrSetup_Upper GROUPSLOWERSUPPER UOGSetup-sGrouprSetup_LowerrSetup_Upper Compatibility Changeover Data The Compatibility or Changeover Data is operation-group centric in that on the same unit between different operation-groups IMPL allows for what we call “purging” “prohibiting” “phasing” and “postponing”. “Purging” is the usual repetitive maintenance activity task or operation that will be setup between the “from” operation-group shutdown and the “to” operation-group startup where the last field must be a configured and known operation on the unit – see Kelly and Zyngier"An improved modeling of sequence-dependent switchovers for discrete-time scheduling problems" IER 46 2007 for details. sUnitsOperationGroupsOperationGroupsOperation UNITOGROUP OGROUP2OPERATION sUnitsOperationGroupsOperationGroupsOperation If the last field is configured as “prohibited” then IMPL will not allow or will forbid any “from” operation- group “to” operation-group sequence transition or precedence and if “phased” will force or only allow the “from” operation-group to be followed by the “to” operation-group. “Postponing” as a word is not used explicitly where instead a lower and upper down-timing can be configured which will force or maintain the unit to be shutdown in between when the “from” operation- group is followed by the “to” operation-group. sUnitsOperationGroupsOperationGrouprDownTiming_LowerrDownTiming_Upper
  • slide 9: UNITOGROUP OGROUP2LDOWNTIMEUDOWNTIME sUnitsOperationGroupsOperationGrouprDownTiming_LowerrDownTiming_Upper Cost Data The Cost Data for logic is straightforward where again we have a profit-weight performance1-weight 1- norm deviations from target performance2-weight 2-norm and penalty-weight for each unit- operation as well as unit-operation-port-state-unit-operation-port-state set of objective function weights. sUnitsOperationrSetupPro_Weight rSetupPer1_WeightrSetupPer2_WeightrSetupPen_Weight UNITOPERATIONWSPROWSPER1WSPER2 WSPEN sUnitsOperationrSetupPro_Weight rSetupPer1_WeightrSetupPer2_WeightrSetupPen_Weight In addition for unit-operations of type batch-process and parcel we also have weights for their startup variables when required. sUnitsOperationrStartupPro_Weight rStartupPer1_WeightrStartupPer2_WeightrStartupPen_Weight UNITOPERATIONWSPROWSPER1WSPER2 WSPEN sUnitsOperationrStartupPro_Weight rStartupPer1_WeightrStartupPer2_WeightrStartupPen_Weight sUnitsOperationsPortsStatesUnitsOperationsPortsStaterSetupPro_Weight rSetupPer1_WeightrSetupPer2_WeightrSetupPen_Weight UNITOPERATIONPORTSTATE UNIT2OPERATION2PORT2STATE2WSPROWSPER1WSPER2 WSPEN sUnitsOperationsPortsStatesUnitsOperationsPortsStaterSetupPro_Weight rSetupPer1_WeightrSetupPer2_WeightrSetupPen_Weight Configuring logic penalty-weights are useful when the MILP declares the problem to be “integer- infeasible”. Although it takes effort to determine the root cause fault defect etc. given the symptoms effects or activities of the infeasibility manifested into IMPL’s excursion variables they can provide some amount of diagnostic and troubleshooting capability by helping to isolate situate or locate the region or area in the problem that is inconsistent. MILP presolvers are also very powerful at detecting and isolating integer-infeasibilities where they will usually display either a single variable or constraint that is inconsistent and can be used to aid in the diagnosis. In terms of the size of the logic penalty-weights a general rule-of-thumb or heuristic is to take the magnitude of the objective function when there are no infeasibilities present and multiply by at least two 2.
  • slide 10: Content Current Data The Content or Current Data configures the opening setup logic for unit-operations and unit-operation- port-state-unit-operation-port-states in the past/present time-horizon. sUnitsOperationrSetup_ValuerStart_Time UNITOPERATIONSVALUESTART sUnitsOperationrSetup_ValuerStart_Time sUnitsOperationsPortsState sUnitsOperationsPortsStaterSetup_ValuerStart_Time UNITOPERATIONPORTSTATEUNIT2OPERATION2PORT2STATE2SVALUESTART sUnitsOperationsPortsState sUnitsOperationsPortsStaterSetup_ValuerStart_Time For pool unit-operations only we have a “drawing” or “filling” string value that must be configured only for those pool unit-operations that have non-zero holdup openings. For example if a pool is multi- product i.e. has more than operation configured then only one of the pool unit-operations needs to have a “drawing”/”filling” opening string value feature or record. The other pool unit-operations will be ignored since they are not defined at the beginning of the time-horizon. sUnitsOperationsDrawingFilling_ValuerStart_Time UNITOPERATIONSVALUESTART sUnitsOperationsDrawingFilling_ValuerStart_Time Command Control Data The Command or Control Data configures the order transaction or proviso details of how the lower and upper hard bounds can vary over time for unit-operation setups and startups and unit-operation-port- state-unit-operation-port-state setups. sUnitsOperationrSetup_LowerrSetup_UpperrBegin_TimerEnd_Time UNITOPERATIONSLOWERSUPPERBEGINEND sUnitsOperationrSetup_LowerrSetup_UpperrBegin_TimerEnd_Time sUnitsOperationrStartup_LowerrStartup_UpperrBegin_TimerEnd_Time
  • slide 11: UNITOPERATIONSLOWERSUPPERBEGINEND sUnitsOperationrStartup_LowerrStartup_UpperrBegin_TimerEnd_Time sUnitsOperationsPortsStatesUnitsOperationsPortsState rSetup_LowerrSetup_UpperrBegin_TimerEnd_Time UNITOPERATIONPORTSTATEUNIT2OPERATION2PORT2STATE2SLOWERSUPPERBEGINEND sUnitsOperationsPortsStatesUnitsOperationsPortsState rSetup_LowerrSetup_UpperrBegin_TimerEnd_Time To configure free or finite logic variables that will be declared as binary variables in the optimization the lower bound should be set to zero 0 and the upper bound to one 1. To configure fixed or forced logic variables the lower and upper bounds should be equal to either zero 0 or one 1 i.e. off closed/inactive or on open/active respectively. An important aspect of IMPL’s logic order digitization or discretization from continuous-time to discrete- time is that the order lower and upper bounds are cumulative aggregated or additive in nature. Thus when multiple orders are specified for the same time-period then the transactions are digitized incrementally where they always start at a lower and upper bound of zero 0. For instance to con
  • Related Search
    We Need Your Support
    Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

    Thanks to everyone for your continued support.

    No, Thanks