Hello, I'm Ed Hughes, the product manager for SAS/OR
and SAS Optimization.
Our focus in this video is the use
of the OPTMODEL procedure in SAS Optimization
8.1 on the SAS Viya platform.
At the heart of the SAS Viya architecture
is the Cloud Analytics Services server, or CAS server.
The CAS server is specifically designed
to analyze very large data sets, and it also
supports parallel computation, both threaded computation
on a single node and distributed computation on multiple server
nodes.
This enables statistical and machine learning algorithms
to scale to massive amounts of data.
However, it's important to point out that typical optimization
problems have comparatively small data
and yet involve highly memory and CPU-intensive computations.
An optimization problem can take a long time
to solve, despite its small input data.
For this reason, SAS optimization on Viya
implements more of a big computing paradigm
than a big data paradigm.
A corollary is that data can be moved or replicated
as needed to gain additional computing capability.
Because moving and replicating comparatively small data
isn't expensive, another aspect specific to optimization
is that the magnitude of performance improvements
in optimization algorithms from using distributed processing
can vary on a case by case basis.
There are even situations where using more nodes
can increase computation time.
And thus, it's important to be able to specify
a number of nodes that's appropriate for this specific
situation.
We'll see how PROC OPTMODEL and SAS Optimization 8.1
supports this capability.
First, a quick review of the structure of a typical PROC
OPTMODEL program.
This is a simple example of a knapsack problem,
in which you're given a knapsack, or any container,
with a weight capacity and a set of items
with corresponding weights and values.
The optimization problem is to find
a subset of items that maximizes the total value
of the items chosen and satisfies the overall weight
restriction.
This section of the program describes the algebraic model
for the problem, using a binary integer programming formulation
based on the optimization-specific syntax
and structures the PROC OPTMODEL provides.
Next, we attach a set of data elements,
which can come from any library accessible to SAS.
This creates a single optimization problem instance.
The third step is to call the appropriate optimization solver
by the solve statement.
When PROC OPTMODEL encounters a solve statement,
it builds a representation of the problem instance
and runs the appropriate solver.
Here we use the Mixed Integer Linear Programming solver,
abbreviated as the MILP solver.
Initially, we solve the problem once
with a capacity value of 40.
We create this problem instance and execute the solver
on the SAS server.
These three high level steps, algebraic model description,
attaching a data instance, and invoking a solver,
occur for any optimization model that you build
and solve in PROC OPTMODEL.
To keep things brief, we omit the additional step
of writing out the details of the optimization solution.
You can also use the programming features of PROC OPTMODEL.
The next section of this program illustrates
using the concurrent 4, or COFOR loop, which
enables you to solve a set of independent optimization
scenarios in parallel.
In this example, we are solving 10 problem instances
with a capacity ranging between 30 and 48.
This helps us investigate how changes in capacity
affect the optimal solution.
On a single server, the COFOR loop
would use threads to implement this parallel approach.
Next, we'll use this example to show how easily you can modify
a PROC OPTMODEL program in SAS/OR
to run in SAS Optimization on Viya.
Let's assume that a CAS server has been started,
and you have access to a CAS session called SAS CASS
1 on that server.
This CAS server instance and CAS session
might be running on hardware that
is distinct from the SAS server where
your SAS code gets executed.
It might even be running in the cloud.
In SAS optimization on Viya, PROC OPTMODEL has a new option
called SESSREF=, shown here in the first line of the program,
which allows you to specify a CAS session with which you want
PROC OPTMODEL to interact.
Elsewhere in the program, the algebraic model declaration
and associating data with the algebraic model formulation
stay exactly as they were before.
In SAS Optimization, PROC OPTMODEL
allows access to data from any type of library
that is accessible from the SAS server.
The data could be in CAS tables, provided
they are accessible from the session SAS CAS 1.
Any data set or table referred to in any read
data statement is copied to the SAS server.
And remember, this is not a big cost because of the small data
sizes.
PROC OPTMODEL builds the problem instance
on the SAS side using these data whenever
it executes a solve statement.
Because we've specified the CAS session by using the SESSREF=
option, PROC OPTMODEL ports the problem instance over
to the CAS server.
And the MILP solver runs in the CAS session SASCAS1
to solve the problem instance.
In this case, the threaded single machine solver
is invoked on a server node that is chosen randomly
from the nodes assigned to the session SASCAS1.
The solution is brought back to the SAS server
for further processing.
Note that the user experience is almost
exactly the same as in SAS/OR.
The only change is that the solver
executes on the CAS server.
The user sets the options SESSREF= to the name of the CAS
session.
PROC OPTMODEL manages everything else
in a way that is invisible to the user.
In SAS Optimization, the COFOR loop in PROC OPTMODEL
uses distributed processing on the CAS server.
The independent runs of the MILP solver algorithm
that correspond to the COFOR loop iterations
are distributed among the available server
nodes associated with the CAS session SASCAS1.
Each of the 10 solver calls is solved on a single server
node in the default threaded mode,
so each solver call is using local parallelism as well.
PROC OPTMODEL waits for all computations to be completed,
collects all the results, and then executes any statements
that follow the COFOR loop.
The decreasing computation time depends
on the number of server nodes available
and on how well balanced the distributed solver related
computations are.
In this example, we have a COFOR loop that has 10 iterations.
Suppose the session has 10 nodes,
and the model building time is minimal compared
with the solver runtimes.
Assume the problem instance for each iteration needs
20 minutes to solve.
In this case, each MILP solver call
will likely be solved on a separate node,
meaning that just 20 minutes will be required overall.
The speed up factor due to this distributed COFOR loop
is close to 10 compared to a sequential FOR loop, which
would take around 200 minutes.
At the other extreme, assume one instance
needs 20 minutes to solve, and the remaining nine instances
need just 1 minute each.
Again, 20 minutes are needed overall,
but here the speed up factor will be close to just 1.5
compared to a sequential FOR loop, which
would take around 29 minutes.
Even though the COFOR loop executes an obviously parallel
computation task, the computational gains
from using distributed computing can vary greatly
depending on the details.
In this example, we used the default threaded MILP solver.
But this is just one of the solvers
accessible from PROC OPTMODEL.
This is the complete list.
The superscript D indicates support
for execution in distributed mode.
In all other cases, the solver runs on one server node,
and a superscript T indicates that the solver
runs in threaded mode.
It's important to remember that this family of solvers
for PROC OPTMODEL and SAS Optimization
includes those available with PROC OPTMODEL in SAS/OR
and the solvers available with PROC OPTMODEL in SAS
High-Performance Optimization.
Additional distributed algorithms
are available only on the SAS Viya platform.
Two prominent examples are a new concurrent MILP solver
and a new distributed shortest path
algorithm for multiple source and sink pairs.
Shortest path is one of the 11 network optimization
algorithms.
Because the gains from distributing
optimization-related computing across server nodes
can vary from case to case, it's important to be
able to choose a number of nodes that's
well-suited for a particular computation.
This is especially useful with PROC OPTMODEL
because it's normal for a single program
to contain several calls to different solvers.
This example shows how you enable this flexibility
in PROC OPTMODEL.
Most of the PROC OPTMODEL code is the same as before,
except that for the first solve, we invoke the concurrent MILP
solver, which has a distributed implementation.
If we assume the current CAS session, SASCAS1, has 10 server
nodes, then execution of this algorithm
is distributed over those 10 nodes.
Now assume the next COFOR loop needs
to run through 100 iterations, and the MILP solver
is invoked once in each iteration.
We've created another CAS session, SASCAS100,
which runs on 100 nodes.
You can submit a statement within the same PROC OPTMODEL
call to reset the current cast session to SASCAS100.
This means any further solves will be submitted
to this new CAS session.
Thus the 100 COFOR loop solves are submitted to the 100 server
nodes.
You can change the current cast session as many times as you
need using similar resets of the SASSREF= option.
As you use PROC OPTMODEL in SAS Optimization,
you'll see there is minimal change in syntax from SAS/OR.
In SAS Optimization, PROC OPTMODEL
accepts both SAS data sets and CAS tables as input.
It builds problem instances on the SAS side,
but the optimization solvers execute in a CAS session,
which you specify using a PROC OPTMODEL option, SASREF=.
You can access multiple CAS sessions
from a single PROC OPTMODEL call by resetting this option.
This is an important feature given the varying benefits
of distributed computation as a function
of the number of nodes.
This has been a brief look at using PROC OPTMODEL and SAS
Optimization 8.1 on the SAS Viya platform.
I hope you found this video instructive and thanks
for watching.