1. Maritime Industrial Shipping, Industrial Modeling Framework (MIS-IMF)
J.D. Kelly1 & A. Vazacopoulos2
i n d u s t r IAL g o r i t h m s
January, 2013
Introduction to Maritime Industrial Shipping, UOPSS and QLQP
Presented in this short document is a description of what is typically known as a marine
industrial shipping problem as opposed to liner or tramp shipping (Christiansen et. al. 2004 and
Jetlund and Karimi, 2004). It is also known as a "maritime inventory routing problem" (MIRP)
given that it involves both immobile (tanks) and mobile (ships) inventory management
(Christiansen et. al., 2007 and Goel et. al., 2012).
Figure 1 below depicts two processing unit-operations (batch and continuous) producing
product stocks C, D and E from feed stocks A and B. Each product has dedicated storage from
which these materials are marine transported via three ships to two customers each with and
without inventory. The ships have two possible routes each with varying size and number of
cargoes (compartments or holds) to store products C, D and E destined for either of its two
customers. All of the materials are in the liquid phase where the shipping is for liquid-bulk only.
Figure 1. Maritime Industrial Shipping Flowsheet Example.
1
jdkelly@industrialgorithms.ca
2
alkis@industrialgorithms.com
2. A full description of the objects found in Figure 1 (as well as other objects not shown) can be
found in Kelly (2004) and Zyngier and Kelly (2009) and is based on our Unit-Operation-Port-
State Superstructure (UOPSS) and our Quantity-Logic-Quality Phenomena (QLQP) (Kelly,
2005). In UOPSS, the units represent physical equipment which can have one or more
procedural operations assigned, attached or associated with it. The cross-product of a unit with
an operation creates a projectional unit-operation which is sometimes referred to as a virtual,
logical or hypothetical object. We impose symmetry with the projectional port-state where the
port is physical and the state is procedural where the state characterizes the type of substance
passing through the port-state. Connectivity is modeled as paths between unit-operations and
port-states and represents the flow of something. The key idea of UOPSS is its ability to
explicitly manage the fact that a single unit can have multiple operations each with a different
configuration of port-states (e.g., SHIP2 and SHIP3 in Figure 1) and allows for very complex
flowsheets to be depicted graphically. An important notion that we exploit with respect to the
QLQP is our novel phenomenological decomposition3 of logistics and quality. Logistics is the
combination of quantity and logic where quantities are flows, holdups, yields and rates and the
logic aspects are related to the setup, startup, switchover, shutdown, status, etc. (Kelly and
Zyngier, 2007) of unit-operations and is solved using mixed-integer linear programming (MILP),
meta-heuristics (Genetic Algorithms, Simulated Annealing, etc.) and/or constraint programming
(CP).
The industrial shipping model presented above is MILP4 based but most process industry
production or manufacturing problems also contain a quantity times quality (sub-)problem due to
intensive variables such as densities, components, properties and conditions multiplied by
extensive quantities such as flows and holdups and is solved using nonlinear programming
(NLP). Furthermore, our modeling framework is based on a discrete-time time-indexed
formulation which requires each time-period to have the same time duration. Other time-
indexed formulations classed as continuous-time models are available and have several
variations based on whether the asynchronous time-periods are defined for a global/common
time grid or local/specific to each unit. However, for our industrial planning and scheduling
problems we have found discrete-time to be not only computationally effective (Maravelias,
2012) but also appropriate when dealing with the many nuances of the problem specification
especially handling partially specified plans or schedules in the future i.e., manually locking or
fixing certain future activities and solving around or between them. This is very important for
industrial decision-making problems where some level of transparency for the user, modeler or
analyst is required in terms of how the planning or scheduling solution is computed from
essentially black-box solvers5.
Industrial Modeling Framework (IMF), IMPRESS and SIIMPLE
To implement the mathematical model of this and other systems, Industrial Algorithms offers a
unique approach and is incorporated into our Industrial Modeling and Pre-Solving System we
call IMPRESS. IMPRESS has its own modeling language called IML (short for Industrial
Modeling Language) which is a flat or text-file interface as well as a set of API's which can be
called from any computer programming language such as C, C++, Fortran, Java, C# or Python
called IPL (short for Industrial Programming Language) to both build the model and to view the
3
Other decompositions are well known such as hierarchical, structural, spatial and temporal but the concept
of phenomenological decomposition is new at least in name for advanced planning and scheduling problems.
4
Although MH and CP as well as local search (LS) solvers can be integrated, at present they are not.
5
Most industrial scheduling applications are still simulation-based where the schedules are built manually and
incrementally one decision at a time so feedback in terms of cause and effect is important to the user.
3. solution. Models can be a mix of linear, mixed-integer and nonlinear variables and constraints
and are solved using a combination of LP, QP, MILP and NLP solvers such as COINMP, GLPK,
LPSOLVE, SCIP, CPLEX, GUROBI, LINDO, XPRESS, CONOPT, IPOPT and KNITRO as well
as our own implementation of SLP called SLPQPE (successive linear & quadratic programming
engine) which is a very competitive alternative to the other nonlinear solvers.
The underlying system architecture of IMPRESS is called SIIMPLE (we hope literally) which is
short for Server, Interacter (IPL), Interfacer (IML), Modeler, Presolver Libraries and Executable.
The Server, Presolver and Executable are primarily model or problem-independent whereas the
Interacter, Interfacer and Modeler are typically domain-specific i.e., model or problem-
dependent. Fortunately, for most industrial planning, scheduling, optimization and control
problems found in the process industries, IMPRESS's standard Interacter, Interfacer and
Modeler are well-suited and comprehensive to model the most difficult of production and
process complexities allowing for the formulations of ubiquitous conservation laws, detailed
constitutive relations and other necessary side constraints.
User or adhoc constraints can be augmented or appended to IMPRESS when necessary in
several ways. For MILP or logistics problems we offer user-defined constraints configurable
from the IML file or the IPL code where the variables and constraints are referenced using unit-
operation-port-state names and the quantity-logic variable types. It is also possible to import a
foreign LP file (row-based MPS file) which can be generated by any algebraic modeling
language or matrix generator. This file is read just prior to generating the matrix and before
exporting to the LP, QP or MILP solver. For NLP or quality problems we offer user-defined
formula configuration in the IML file and single-value and multi-value function blocks writable in
C, C++ or Fortran. The nonlinear formulas may include intrinsic functions such as EXP, LN,
LOG, SIN, COS, TAN, MIN, MAX, IF, LE, GE and KIP, LIP, SIP (constant, linear and monotonic
spline interpolation) as well as user-written extrinsic functions.
Industrial modeling frameworks or IMF's are intended to provide a jump-start to an industrial
project implementation i.e., a pre-project if you will, whereby pre-configured IML files and/or IPL
code are available specific to your problem at hand. The IML files and/or IPL code can be
easily enhanced, extended, customized, modified, etc. to meet the diverse needs of your project
and as it evolves over time and use. IMF's also provide graphical user interface prototypes for
drawing the flowsheet as in Figure 1 and typical Gantt charts and trend plots to view the solution
of quantity, logic and quality time-profiles. Current developments use Python 2.3 and 2.7
integrated with open-source Dia and Matplotlib modules respectively but other prototypes
embedded within Microsoft Excel/VBA for example can be created in a straightforward manner.
However, the primary purpose of the IMF's is to provide a timely, cost-effective, manageable
and maintainable deployment of IMPRESS to formulate and optimize complex industrial
manufacturing systems in either off-line or on-line environments. Using IMPRESS alone would
be somewhat similar (but not as bad) to learning the syntax and semantics of an AML as well as
having to code all of the necessary mathematical representations of the problem including the
details of digitizing your data into time-points and periods, demarcating past, present and future
time-horizons, defining sets, index-sets, compound-sets to traverse the network or topology,
calculating independent and dependent parameters to be used as coefficients and bounds and
finally creating all of the necessary variables and constraints to model the complex details of
logistics and quality industrial optimization problems. Instead, IMF's and IMPRESS provide, in
our opinion, a more elegant and structured approach to industrial modeling and solving so that
you can capture the benefits of advanced decision-making faster, better and cheaper.
4. MIS-IMF Modeling Details
At this point it is prudent to elucidate more of the modeling details found in Figure 1. With
respect to the production facility or plant, it is represented by a supply of raw materials A and B
which can be used to produce finished product C in a batch-process unit-operation labeled
ABC. Batch-processes exhibit a distinct "fill-hold-draw" holdup or inventory profile over time
(Zyngier and Kelly, 2009) where the feeds can be filled or loaded into the batch vessel either
continuously or intermittently over the duration of the batch known as its cycle or processing-
time. Finished products D and E are produced in a continuous-process unit-operation named
BDE requiring only B. Continuous-processes exhibit no or negligible holdup during the
processing and as such simultaneously produce D and E the instant B is available where the fill-
hold-draw profile collapses to a concurrent fill-draw with no hold of course. Because there are
two flows in and one flow out for the batch-process, this type of process is also known as
convergent flow path. One flow in with two or more flows out is known oppositely as divergent
flow path where both types are found often and together in the process industries as in our
example. These types of processes can be modeled easily with IMPRESS given our use of
port-states.
Port-states allow flow into and out of a unit-operation and can be considered as flow-interfaces
similar to ports on a computer i.e., nozzles, spouts, spigots. Port-states also provide an
unambiguous description of the flowsheet or superstructure in terms of specifically what type of
materials or resources are being consumed and produced by the unit-operation. Port-states
can also represent utilities (steam, power), utensils (operators, tools) as well as signals such as
data, time, tasks, etc. Each of the three products C, D and E have tanks available for storage
and is a requirement when balancing the production-side supply with the transportation-side
demand of the value-chain. Finally, the lines or arcs between the unit-operations and port-
states and across an upstream unit-operation-port-state to a downstream unit-operation-port-
state correspond to flows as one would except given that the superstructure is ultimately
composed of a network or graph of nodes/vertices and arcs/edges (directed).
We now feature the industrial shipping details of the problem where the inverted triangle in
Figure 1 indicates what we call a parcel unit-operation i.e., any vessel that moves material from
location to location on land or sea. SHIP1 can carry cargoes of C and D of variable size
according to two routes and delivers these products to their respective CUSTOMER1 each with
on-site storage tanks. The different routes can relate to different shipping channels (requiring
different amounts of travel or hauling-time) where the order or sequence of delivery (unloading)
i.e., C then D or D then C, is fundamentally set by the release and due-dates of the customer
orders. Usually the time-windows (difference between the release and due-dates) are three-
days in length and is referred to as the laytime or laycan of the ship at the berth, jetty or wharf6.
Deviations outside these time-windows may incur demurrage charges depending on the berth's
utilization and can be setup as penalties in the optimization either on the quantity or the logic
variable for the corresponding time-period.
One of the most important aspects of industrial shipping is the round-trip or return-trip time from
the plant to one or more customers and then back to the plant to continue the cycle. During the
loading (filling) at the plant then hauling (holding) or traveling to the customer(s) for unloading
6
A harbor or marine port will have one or more berths and may include single point/buoy mooring for very
large ships (VLCC's) which will then require what is known as the operation of lightering. This will then require
berth-assignment details and a sub-shipping model to be configured to also manage the lightering ships (i.e., tugs
and barges).
5. (drawing) there is obviously a dead-time where the ship must return back to the plant. During
this time the ship can neither load nor unload where it must not be engaged in any other
operation, task or activity. The sum of all of these times; loading, hauling, unloading, returning
is called the round-trip time and is surprisingly similar to the way a batch-process operates in a
plant. Hence, the parcel unit-operation is modeled identical to a batch-process unit-operation
except that the parcel unit-operation has one or more batch or cargo-sizes (as indicated by the
matching inlet and outlet port-states in Figure 1) whereas the batch-process unit-operation has
only one batch-size.
SHIP2 also has two possible routes but ROUTE1 has two cargoes C and D going to their
respective CUSTOMER1 and ROUTE2 adds cargo E destined for CUSTOMER1 but C and D
cargoes go to their respective CUSTOMER2. This is an example where the same physical ship
can have different routes with different cargoes going to different customers. SHIP3 also has a
different arrangement of port-states or cargoes for each of its routes where ROUTE1 carries two
cargoes each of C and E assigned to different customers. ROUTE2 is similar with two cargoes
each of D and E. The deliveries of material to CUSTOMER1 can be unloaded to a pool unit-
operation or tank where CUSTOMER2 either has no inventory buffer or it is not known to this
problem. For these types of demand points we have two uses or options we call contiguous
and non-contiguous. Contiguous use is similar to a pipeline connection where the flows must
be within lower and upper bounds for each time-period as specified by the demand order. Non-
contiguous use relaxes this restriction by defining a release and due-date or time-window and a
holdup lower and bound. In order to not incur an infeasibility, the solution must ensure that
within the time-periods defined by the time-interval the aggregated or summed flow (equal to the
holdup) must be within bounds.
MIS-IMF Solving Details
Once the flowsheet has been configured as in Figure 1, a *.UPS file (short for UOPSS) is
constructed using the UOPSS object names via a Python 2.3 macro (IALconstructer.py)
embedded in the Dia drawing package and is shown in Appendix A. This file can then be
included into the IML file or the IPL code and will define the necessary named keys or index-
sets for the various capacity data necessary to create the mathematical model. A useful facet of
the UPS file is the application of "aliases". Aliases allow the capacity configuration of many
UOPSS objects simultaneously - see ALLPARTS, ALLINPORTS, ALLOUTPORTS and
ALLPATHS.
TBD
References
Christiansen, M., Fagerholt, Ronen, D., "Ship routing and scheduling: Status & Perspective",
Transportation Science, 38, 1, (2004).
Jetlund, A., Karimi, I.A., "Improving the logistics of multi-compartment chemical tankers",
Computers & Chemical Engineering, 28, 1267, (2004).
Kelly, J.D., "Production modeling for multimodal operations", Chemical Engineering Progress,
February, 44, (2004).
6. Kelly, J.D., "The unit-operation-stock superstructure (UOSS) and the quantity-logic-quality
paradigm (QLQP) for production scheduling in the process industries", In: MISTA 2005
Conference Proceedings, 327, (2005).
Christiansen, M., Fagerholt, Nygreen, B., Ronen, D., "Maritime transportation", In: C. Barnhart &
G. Laporte, Eds., Transportation. Handbook in Operation Research & Management Science,
14, 189, (2007).
Kelly, J.D., Zyngier, D., "An improved MILP modeling of sequence-dependent switchovers for
discrete-time scheduling problems", Industrial & Engineering Chemistry Research, 46, 4964,
(2007).
Zyngier, D., Kelly, J.D., "Multi-product inventory logistics modeling in the process industries", In:
W. Chaovalitwonse, K.C. Furman and P.M. Pardalos, Eds., Optimization and Logistics
Challenges in the Enterprise", Springer, 61-95, (2009).
Goel, V., Furman, K.C., Song, J-H, El-Bakry, A., "Large neighborhood search for LNG inventory
routing", Journal of Heuristics, 18, 821, (2012).
Maravelias, C.T., "On the combinatorial structure of discrete-time MIP formulations for chemical
production scheduling", Computers and Chemical Engineering, 38, 204, (2012).
Appendix A - MIS-IMF.UPS (UOPSS) File
i n d u s t r I A L g o r i t h m s
All Rights Reserved (c)
checksum,288
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Unit-Operation-Port-State-Superstructure (UOPSS) *.UPS File.
! (This file is automatically generated from the Python program IAConstructer.py)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
&sUnit,&sOperation,@sType,@sSubtype,@sUse
A,,perimeter,,
ABC,BATCH,processb,,
B,,perimeter,,
BDE,CONTINUOUS,processc,,
C,,pool,,
C_CUSTOMER1,C,perimeter,,
C_CUSTOMER1,C,pool,,
C_CUSTOMER2,C,perimeter,,
D,,pool,,
D_CUSTOMER1,D,perimeter,,
D_CUSTOMER1,D,pool,,
D_CUSTOMER2,D,perimeter,,
E,,pool,,
E_CUSTOMER1,E,pool,,
E_CUSTOMER1,E,perimeter,,
E_CUSTOMER2,E,perimeter,,
SHIP1,ROUTE1,parcel,,
SHIP1,ROUTE2,parcel,,
SHIP2,ROUTE1,parcel,,
SHIP2,ROUTE2,parcel,,
SHIP3,ROUTE1,parcel,,
SHIP3,ROUTE2,parcel,,
&sUnit,&sOperation,@sType,@sSubtype,@sUse
! Number of UO objects = 22
&sAlias,&sUnit,&sOperation
ALLPARTS,A,
ALLPARTS,ABC,BATCH
ALLPARTS,B,
ALLPARTS,BDE,CONTINUOUS
ALLPARTS,C,
ALLPARTS,C_CUSTOMER1,C
ALLPARTS,C_CUSTOMER1,C
ALLPARTS,C_CUSTOMER2,C
ALLPARTS,D,
ALLPARTS,D_CUSTOMER1,D
ALLPARTS,D_CUSTOMER1,D
ALLPARTS,D_CUSTOMER2,D
ALLPARTS,E,
