Wednesday, October 5, 2011

OptimJ is now free, but Ateji is closed

Atjei, the creater of OptimJ, is now closed. The OptimJ product is a Java extension that supports a simplified syntax for specifying optimization models.  It is sad to see this product be abandoned like this.  I do not know of any other optimization modeling tool that directly supports Java.

Erwin Kalvelagen noted the demise of Ajeti, and commented that "I believe that some of the more complex data issues in practical modeling are often better (i.e. more efficiently) dealt with in a specialized language than in a traditional programming language." Pyomo is similar to OptimJ, in that it supports optimization modeling in Python. However, a premise that has guided Pyomo development is that users will want to perform modeling in a full-featured programming language.

Clearly, traditional programming languages are more verbose and complex than a domain-specific language. However, Python is arguably much simpler to use than Java. In fact, I have gotten feedback from Pyomo users that suggests that they were not aware that they were developing models in Python;  they simply thought that it was another modeling language!

Of course, I am a programmer who likes to do optimization.  My selfish reason for creating Pyomo is that I find domain-specific languages quite constraining.  In fact, I had thought that the use of Python for modeling and optimization would be attractive to optimization researchers.  Python is a great language for prototyping a complex idea, usually without losing too much performance.  I and other Pyomo developers have implemented complex optimizers in Python that directly interface with Pyomo models, and in most cases the runtime is dominated by LP subproblems.  Thus, there has been little motivation to develop custom, highly-optimized codes in languages like C++ based on these solvers.

Friday, September 23, 2011

Using AsciiDoc for Mathematical Publications

Technical writing is an integral part of my research in computer science and operations research. I have a long history using LaTeX, which is very well suited for writing technical articles that contain mathematical equations as well as code snippets. Although LaTeX can readily generate postscript and PDF output files, I have been unimpressed with tools that generate HTML from LaTeX source. Thus, I was intrigued by AsciiDoc, which promises to generate PDF, HTML and eBook formats. AsciiDoc is used to provide online documentation for software projects, and authors can publish book through O'Rielly using this tool. Thus, this is a well-developed document generation tool.

I have successfully prototyped a draft book, Getting Started with Coopr, and you can browse the subversion repository for this document here. Note that the Makefile file specifies build targets for PDF, HTML and eBook files.

The advantage of AsciiDoc is that you can use a simple markup language to generate complex documents in a variety of formats. Since this is a generic document-generation process, it is reasonable to expect that there will be limited control of document formatting. (If you want a lot of control, you should just use LaTeX!) However, there are several major limitations to the document generation and format control that limit what you can do with AsciiDoc:

  • Portable Mathematical Equations:  There is only limited support for generating eBook documents that contain mathematical equations.  I noticed that the ePUB standard was just updated this month to support MathML, so it is not clear that e-readers can handline MathML right now.  Additionally, AsciiDoc does not support the generation of the MathML XML from a high-level description (e.g. LaTeX math equations).  Thus, a user cannot easily prepare a document that generates both PDF (using LaTeX under the hood) and ePUB (using MathML under the hood).  I guess we will have to wait a few more years to see robust publishing of mathematics for eBooks.

  • Formatting Mathematics:  For whatever reason, the default formatting of mathematical environments in HTML is not centered or indented (as it is in LaTeX).  Thus, it is much more difficult to read HTML documents containing mathematics.  I tried resolving this using an AsciiDoc filter, without luck.  I wound up rewriting the LatexMath macros to enforce this different formatting in HTML.  Unfortunately, these revised macros do not precisely match the syntax used by AsciiDoc.  {sigh}

  • Document Authors:  The AsciiDoc markup language does not provide a convenient way to create a document with multiple authors.  Yes, I am not kidding.  There is a docbook configuration file that you can provide, which only works if the document generation process goes through docbook;  in my example, that works for ePUB and PDF files.  Thus, there does not appear to be a single, portable way for specifying multiple authors.
  • Citations: It is noteworthy that none of the examples of online books referenced in the online AsciiDoc documentation contain citations or a bibliography.  The default format for bibliographies in AsciiDoc PDF files is as a numbered chapter or section, which differs from the normal convention in LaTeX (which I much prefer).  Thus, my AsciiDoc book uses the colophon section, which is not numbered.  However, that means that it does not show up in the table of contents.  {sigh}

    Another issue with citations is that the examples provided by AsciiDoc do not correctly generate hyperlinks in the PDF file.  Basically, the bibliography section type provided by AsciiDoc does not work well with the dblatex tool used to generate the PDF.  My solution was to not use the bibliography section type!

    Finally, the examples provided by AsciiDoc include citations in a list environment, which means that the PDF output contains a numbered list followed by a bracket citation reference.  Again, my solution was to avoid using the list;  the bibliography is simply a sequence of paragraphs, each of which is a citation with its associated anchor.
Despite these issues, I am planning to continue developing the Coopr documentation with AsciiDoc.  The lack of support for mathematical equations is a problem for ePUB documents, but most readers will be using this document to refer to the examples in python.  However, I would not consider using AsciiDoc for developing more complex documents, like a book intended for publication. There is too much customization that would be needed to get past the current limitations.

Friday, August 5, 2011

Coopr Download Fun

I stumbled across the following site, which provides download statistics for PyPI Python optimization packages:

It was fun to see the different download package statistics. I'm quite curious that coopr.pysos has the highest number of downloads, since IMHO this package doesn't have much interesting functionality... Hmmm...

Another surprise for me is that so many optimization Python packages are _not_ on this list!  I am maintaining the following list of links for Python optimization packages:

Perhaps these packages were not tagged with the 'optimization' label ... or perhaps they were not downloaded enough to make the list?

Saturday, July 23, 2011

Python Optimization Packages

I have been maintaining a list of Python optimization packages for a while now on the Coopr Trac pages:  see, I noticed that if you google for "python optimization packages", this page does not show up right away.  Perhaps Trac pages are index differently?  I'm not sure.

Anyway, I thought I'd add this reference here to help others find this list that I'm maintaining...

Coopr 3.0.4362 Release

We are pleased to announce the release of Coopr 3.0 (3.0.4362). Coopr is a collection of Python software packages that supports a diverse set of optimization capabilities for formulating and analyzing optimization models.

The following are highlights of this release:

- Solvers
* More sophisticated logic for solver factory to find ASL and OS solvers
* Various solver interface improvements
* New Solver results object for efficient representation of variable values
* New support for asynchronous progressive hedging

- Modeling
* Changes in rule semantics to limit rule return values
* Changes in the expected order of rule arguments
* Constant sums or products can now be used as constraint bounds
* Added full support for the !ConstraintList modeling component.

- Usability enhancements
* More explicit output from runph and runef commands
* Added support in runef to write the extensive form in NL format
* Add controls for garbage collection in PH

- Other
* Efficiency improvements in generation of NL and LP files.
* Significant efficiency improvements in parsing of Pyomo Data Files.
* More robust MS Windows installer (does not use virtual python
* environment)

Note that this is a major release of Coopr that changes the expected formulation of Coopr models. See the Coopr blog for further details about deprecated functionality, which will be disabled in future releases.

See for instructions for getting started with Coopr. Installers are available for MS Windows and Unix operating systems to simplify the installation of Coopr packages along with the third-party Python packages that they depend on. These installers can also automatically install extension packages from Coin Bazaar.


- Coopr Developer Team

About Coopr

Coopr is a collection of Python software packages that supports a diverse set of optimization capabilities for formulating and analyzing optimization models.

A key driver for Coopr development is Pyomo, an open source tool for modeling optimization applications in Python. Pyomo can be used to define symbolic problems, create concrete problem instances, and solve these instances with standard solvers. Thus, Pyomo provides a capability that is commonly associated with algebraic modeling languages like AMPL and GAMS.

Coopr has also proven an effective framework for developing high-level optimization and analysis tools. For example, the PySP package provides generic solvers for stochastic programming. PySP leverages the fact that Pyomo's modeling objects are embedded within a full-featured high-level programming language, which allows for transparent parallelization of subproblems using Python parallel communication libraries.

Coopr development is hosted by Sandia National Laboratories and COIN-OR:


See for online discussions of Coopr.

Monday, March 28, 2011

Coopr 2.5(2.5.3890) has just been released! Coopr is a collection of Python software packages that supports a diverse set of optimization capabilities for formulating and analyzing optimization models.

The following are highlights of this release:

- Solvers
    * MIP solver interface updates to use appropriate objective names
    * Added support for suffixes in GUROBI solver interface
    * Improved diagnostic analysis of PH solver for the extensive form

- Usability enhancements
    * Improved robustness of coopr_install
    * Fixed Coopr installation problem when using easy_install
    * Added a script to launch the CooprAge GUI.
    * LP files now are written with the true objective name
    * Rework of pyomo command line to create a concise output
    * Many efficiency improvements during model generation!
    * Many improvements to diagnostic output and error handling
    * Expressions like "model.p > 1" can now be used within generation rules

- Modeling
    * Added support for generalized disjunctive programs (in coopr.gdp)
    * Constraints can now be specified in "compound" form:  lb <= expr <= ub
    * Significant robustness enhancements for model expressions
    * Improved error handling for constraint generation

- Other
    * Python 2.5 is deprecated due to performance issues
    * Python versions 2.6 and 2.7 are supported
    * New MS Windows installer is now available

See the Coopr wiki for further details!