AMPL's new expand
command can display any explicit linear constraint, or indexed collection of
constraints. For example:
ampl: model transp.mod;
ampl: data transp.dat;
ampl: expand Demand['STL'];
s.t. Demand['STL']:
Trans['GARY','STL'] + Trans['CLEV','STL'] +
Trans['PITT','STL'] = 1700;
ampl: expand Supply;
s.t. Supply['GARY']:
Trans['GARY','FRA'] + Trans['GARY','DET'] +
Trans['GARY','LAN'] + Trans['GARY','WIN'] +
Trans['GARY','STL'] + Trans['GARY','FRE'] +
Trans['GARY','LAF'] = 1400;
s.t. Supply['CLEV']:
Trans['CLEV','FRA'] + Trans['CLEV','DET'] +
Trans['CLEV','LAN'] + Trans['CLEV','WIN'] +
Trans['CLEV','STL'] + Trans['CLEV','FRE'] +
Trans['CLEV','LAF'] = 2600;
s.t. Supply['PITT']:
Trans['PITT','FRA'] + Trans['PITT','DET'] +
Trans['PITT','LAN'] + Trans['PITT','WIN'] +
Trans['PITT','STL'] + Trans['PITT','FRE'] +
Trans['PITT','LAF'] = 2900;
The expand command also works with variables and objectives, and has
indexing options similar to those of display or print for
determining which components are expanded.
The built-in parameter _nvars contains the number of variables; a
symbolic parameter _varname[j] contains the AMPL name of the
jth variable; and _var[j] is a "synonym" that refers to the
jth variable. Thus to show the names of all variables that are below
their upper bounds at the optimum, for example, you can write:
ampl: display {j in 1.._nvars:
ampl? _var[j] < _var[j].ub - 0.00001} _varname[j];
_varname[j] [*] :=
2 "PD_Ship['SE']"
5 "DW_Ship['NE','BWI']"
6 "DW_Ship['SE','EWR']"
7 "DW_Ship['SE','BWI']"
;
This is only one of the uses for AMPL's generic synonyms for variables,
constraints and objectives. See the discussion of AMPL's new generic synonym feature for more
details.
AMPL's new suffix feature can
be used by solvers to return ranging information. See in particular the
discussion of solver-defined
suffixes for an example of range output from CPLEX. If you are using a
solver that offers ranging, you may need to update the AMPL driver for that
solver in order to get access to the ranging suffixes; see our solver listing for information on solver
vendors and download sites.
AMPL does not currently support "parametric" algorithms for postoptimal
analysis of objective functions or constraint right-hand sides.
In practice, ranging often provides sensitivity information of limited
usefulness, and parametric algorithms are limited to certain kinds of linear
changes to the data. You may do better to write a simple AMPL script that solves
the same model for a series of different parameter values. For an example, see
our writeup on AMPL's new looping
commands and related features for programming in the command language.
AMPL cannot determine by itself the values from the linear programming
tableau, because the sparse linear algebra routines capable of computing these
values are found only in the solvers. Efficient solver implementations avoid
computing or storing more than a few tableau columns at a time, however. Hence
AMPL also has no solver directives that can cause tableau values to be returned.
For a specific AMPL model, it is possible to set up an auxiliary model that
finds the tableau values, at least in the nondegenerate case; see our diet tableau example based on the
diet model from Chapter 2 of the AMPL
book. This approach is highly inefficient, but should be adequate for small
linear programs -- up to a few dozen variables, say.
The display command does not currently recognize {k
in SS} POW[k] where POW is an indexed
(subscripted) set. For this elementary case, you can exhibit the whole indexed
collection of subsets by giving just the name of the collection:
display POW;
You can also exhibit each of the indexed sets separately, by using the
iterated form of the display command; it resembles the ordinary form,
but with a colon after the index set:
display {k in SS}: POW[k];
This gives the same output as if you had typed a separate statement
display POW[k] for each member k of SS. Any
set expression (or list of expressions) may follow the colon.
Add the keyword "ordered" to the set's declaration, after the set
name. It can be useful to declare a set ordered for purposes of
ordering the output, even when the ordering plays no role in the model.
AMPL provides the following built-in timing parameters:
| _ampl_elapsed_time |
elapsed seconds since the start of the AMPL process |
| _ampl_system_time |
system CPU seconds used by the AMPL process itself |
| _ampl_user_time |
user CPU seconds used by the AMPL process itself |
| _ampl_time |
_ampl_system_time + _ampl_user_time |
| |
| _shell_elapsed_time |
elapsed seconds for most recent shell command |
| _shell_system_time |
system CPU seconds used by most recent shell command |
| _shell_user_time |
user CPU seconds used by most recent shell command |
| _shell_time |
_shell_system_time + _shell_user_time |
| |
| _solve_elapsed_time |
elapsed seconds for most recent solve command |
| _solve_system_time |
system CPU seconds used by most recent solve command |
| _solve_user_time |
user CPU seconds used by most recent solve command |
| _solve_time |
_solve_system_time + _solve_user_time |
| |
| _total_shell_elapsed_time |
elapsed seconds used by all shell commands |
| _total_shell_system_time |
system CPU seconds used by all shell commands |
| _total_shell_user_time |
user CPU seconds used by all shell commands |
| _total_shell_time |
_total_shell_system_time +
_total_shell_user_time |
| |
| _total_solve_elapsed_time |
elapsed seconds used by all solve commands |
| _total_solve_system_time |
system CPU seconds used by all solve commands |
| _total_solve_user_time |
user CPU seconds used by all solve commands |
| _total_solve_time |
_total_solve_system_time +
_total_solve_user_time |
These parameters can be used in all the same ways as ordinary AMPL parameters
defined through param statements. Thus in particular you can show their
values by use of display or printf commands.
|