-------------------------------------------------------------------------------
- OPT
- Reorganized pyomo.opt to rely on plugins for most of its core
functionality.
- Changed the default output for PICO to be LP format, rather than
.NL. This avoids issues with name-mapping that we haven't resolved yet.
- Updated LP writer to not output integer/binary status for variables
that aren't referenced in the model.
- In LP output format, modified constraint names to be "suffixed"
with the index in the same fashion as variables. The suffix is "None"
if the constraint is a singleton. Will help debug models during
development/prototyping.
- For MIPs, added "slack" suffix to solutions and modified CPLEX solver
interface to populate the suffix accordingly.
- Improvement of the factory mechanism used to launch optimizers;
solvers can be passed options during construction.
- The CPLEX LP format assumes default variable bounds equal to 0 and
+inf. These conflict with the more sane defaults in Pyomo, which are
-inf and +inf. This leads to all kinds of silent, incorrect behavior
in terms of getting very strange solutions where you are expecting a
straightforward solve. The cpxlp writer was changed to always output
bounds for variables, which is the safest route in any case.
- Added a facility for managing asynchronous events. In particular,
this facility has been setup to support the application of Pyomo
solvers with subclasses of the AsynchronousSolverManager.
- Created a distributed solver manager that uses the Pyro
RPC package.
- Rework of MIP solver interfaces for CPLEX, GLPK, PICO and CBC.
- Using an explicit temporary file when launching the shell command
subprocess, to avoid a buffer overflow.
- A rework of the logic in shellcmd.py to segregate the solution
into preprocess/solve/postprocess. This facilitates a fine-grain
parallelization of just the IP solve, using Pyro.
- If a variable name has the format x(1,a) or x[3,4,5] then create a
dictionary attribute 'x' in the SolverResults object, which maps the
tuple values to the corresponding value.
For example:
results.solution().variable.add('x(1,a)')
print results.solution().variable.x[1,'a']
- A change in the converter semantics. Now, the convert returns a
tuple of filenames. In most cases, this is a singleton tuple. But
in some important cases this is a non-singleton tuple (e.g. AMPL
*.mod/*.dat files).
- PYOMO
- Reworked Pyomo's management of components to use plugins.
- Adding two new components BuildCheck and BuildAction. Their
usage is similar, but their expected use is a it
different. BuildAction allows for the injection of arbitrary build
actions during construction of the model, while BuildCheck is used
to test conditions and generate exceptions when the build process
goes awry.
- There is also a subtle change to the Param component. The following
is now legal:
def f(model):
return 1.3
model.x = Param(initialize=f)
That is, when the Param object does not have an explicit index,
then no index is passed to an initializer function (as is expected).
- Adding 'summation', a function that computes multi-vector
product sums:
sum_i x[i]*y[i]*z[i]
- Adding automatic computation of variable bounds based on the domain.
If the domain set supports simple bounds, then they will be used to
initialize the bounds of a variable.
- Adding logic to ignore the generation of constraints if the
constructor rule returns either 'None' or '0'.
- Changed default domain of a Param to be Any, to be consistent with Set.
- Rework of Pyomo to enable preprocessor actions to manage all
post-instance-generation activities. This includes a simple preprocessor
plugin, which simply applies preprocessor actions in an order specified
by the action-specific ranks. The problem writers are no longer
responsible for how preprocessor actions take place.
NOTE: These preprocessors are very much tailored to the needs of the
NL and LP writers. We need to figure out a mechanism to tailoring
preprocessors to specific target solvers (e.g. tailoring preprocessing
for the NL writer, or tailoring preprocessing for MILP models).
_ The Constraint and Objective classes were reworked to integrate
their data into a single _data dictionary. This simplified
the management of id and label information.
- Extending the Constraint(model.A, rule=f) constructor semantics. This
change allows the rule to return a dictionary when the constraint is
indexed by one or more sets.
- A revision to Pyomo semantics. Now, expressions are not evaluated
when performing arithmetic operations (plus, times, etc).
- A major rework of how component attributes are managed for
NumericValue objects and subclasses of this class. This was driven
by the desire to add the Var.declare_attribute() method, which declares
attributes for variables (which are akin to ampl suffix's).
Most of these changes were motivated by inconsistencies that were
observed within Pyomo, and the desire to better protect declared
attributes. Now, attributes are stored with names that are unlikely
to be used by end-users or other Pyomo developers. Also, declared
attributes can now only be referenced directly. Thus, you cannot
refer to x._value, but instead you must use x.value.
- Reworked the way that 'empty' objectives and constraints are dealt
with. By default, objectives and constraints with expr/body
values of None are provided, which facilitates some aspects of
preprocessing. But this triggered exceptions, which are now disabled.
- Reworked how the '_equality' constraint attribute is managed. This is
now in the ConstraintData class, which required various changes.
- Changed the pprint output for equality constraints to make it clear
that both the upper and lower bounds are equal for these constraints.
- Fixed bug in the definition of parameter names. When using a rule
to define parameter values, the parameter name now reflex the index
values for the parameter.
- Major change of NumericalValue subclass semantics. The 'value' data
member is not supported for expressions, constraints and objectives.
These classes need to use the call method. This simplifies the
logic in their getattr/setattr methods.
- Various code optimizations to improve the runtime performance of Pyomo.
- A major rework of the Pyomo core to eliminates the use
of getattr and setattr methods. Removing these led to a 1/3 reduction
in runtime for some largish p-median test problems. This change
has had the following impact on Pyomo functionality:
. No validation that values assigned to parameters or variables are valid
. Cannot set all suffixes simultaneously
. Cannot set lower/upper bounds simultaneously
. No validation that suffixes are valid when their value is set
Also, this effort led to a rework of the Param and Var classes. These
are now segregated between Element and Array classes (similar to the
Set class). This led to further optimizations of the logic in these
classes. Unfortunately, it also led to the use of the _VarBase and
_ParamBase in the PyomoModel to index components.
- Changed order in which parameters are validated. Validation needs
to occur after parameters are set. This is due to the semantics of
the validation function: we want to allow the validation function to
refer to the value as if it were set.
- Deprecating the use of the expression factory for algebraic expression
types. These are now launched directly from the generate_expression()
function.
- Adding support for specifying options when launching solvers. For example:
results = self.pico.solve(currdir+"bell3a.mps", options="maxCPUMinutes=0.1")
- The value 'None' is accepted by all NumValue objects, and this
indicates that the object has not been initialized.
- ParamValue objects print their name, rather than their value.
- Resolving an issue loading boolean data from a *.dat file. Now,
all true/false strings are changed to True/False values.
- Rework of Pyomo to use the SolverManagerFactory. The default
behavior is to use the 'serial' manager, which does local solves,
but this supports extensibility for other solvers.
- SUCASA
- Added an option to terminate SUCASA after the AMPL script is
generated, but before PICO is called. This allows the AMPL script
to be applied separately.
- Rework of the files generated by SUCASA. Before, SUCASA generated
three files:
. app_milp.h/app_milp.cpp Define the derived MILP classes
. app_extras.cpp Used to define the methods specialized by the user
Now, SUCASA generates five files:
. app_sucasa.h/app_sucasa.cpp Define the derived MILP classes
. app_milp.h/app_milp.cpp Define a MILP from the code in *_sucasa.* files.
. app_extras.cpp Used to define the methods specialized by the user
The result, is that SUCASA now generates two derived solvers. BUT, the
one that is exposed to the user can be customized without impacting
the integration of the Info classes. Further, this segregation
simplifies the class definitions that a user looks at; for example,
there are no ugly ifdefs, and no references to the Info data.
- A rework of the SUCASA API that is exported to the user. This new
API allows users to register the vector of primal/dual values,
which are access implicitly through the methods
<name>_value()
- Rework of the SUCASA Info API to ensure a consistent interface
for sets, parameters, vars, etc.
- Rework of the AMPL parser to guess the superset types for sets and
parameters. This works on most common cases, but it's far from perfect.
- Extended code generation to include parameter data.
- Update of examples.
- PYSP
- Initial integration of the Python Stochastic Programming (PySP) package.
- Developed a variety of stochastic programming examples to illustrate
the use of PYSP
- Developed a PYSP user guide.
- General
- Resolved Python 3.0 portability issues
- Created a script create_pyomo_install, which uses virtualenv to
automatically create the pyomo_install script, which automates the
installation of pyomo.
-------------------------------------------------------------------------------