Add --ecgw argument, and reorganize temoa_solve

This argument conflicts with supplying a data file because it is meant
for a evaluating a stochastic solution.  So this commit also introduces
an explanation to the user of what's going on.

Additionally, prepare temoa_solve for the two modes of operation.  This
is nice because it keeps the functionality tied to temoa_model.py.
Perhaps I can also bring the PySP functionality into the fold ...

I'm also playing with some command line colors to really bring out what
the issue is, rather than have "yet more drab gray text" to scare the
user.  Unfortunately, this is not universal: this only works on
non-Windows systems.  Fixing this so that we can get color on Windows is
on my TODO (wish)list.
Update a --help message.

(LP -> LP file)
This check is no longer necessary.

The original purpose for this check was because there was a bug in
Coopr.  I submitted a patch to fix that bug in Dec, 2011, but I was
hours too late as they had already started their build of Coopr.  A
year later shows the next version of Coopr released, so this is no
longer necessary.
Update stochastic generation script to Coopr API

A couple of Coopr internals upon which this script relied changed.
Updated them to follow Coopr.  I suppose technically this is not an
externally exposed API, but I have not yet thought through how to use
the exposed API for this purpose.
Implement "Expected Cost of Guessing" algorithm

This is a first implementation of the ECGW algorithm.  As such, it is
has only basic functionality:

 * For each scenario, solve it, then
   * set the stage 1 variables, and solve for every other scenario.

One uses it through the --ecgw argument to the Temoa script:

    $ coopr_python  temoa_model  --help
     [...]

    $ coopr_python  temoa_model  --ecgw  path/to/stochastic/tree

It uses the PySP stochastic scenario definition files, so one only need
point it to the same files used for the stochastic analysis.

This returns a CSV file of the data, such that for each "Gambler's
Guess", it shows the total costs involved with guessing the correct
scenario, and incorrectly for each scenario, as well as the variable
values associated with each outcome.

This means that each "incorrect" scenario represents the minimum costs
involved in course correction for that scenario in question.  There is
nothing to say that the costs will be even higher, but these represent
the minimum.

The current difficult part is that Coopr is not great about leakage
between models with different data, so I have to create the temoa model
afresh for each slightly different data set.  This is a little slower
than ideal, but it works.

At this point in time, I am aware of at least one unimplemented
"biggie": parallelism.  The script is entirely serial.  The next
iteration will likely use "easy" parallelism in the form of fork()ed
processes (i.e., only up to the number of processes on the single
compute node running this script).  The bigger gains in parallelism will
come when I implement a cluster-wide ability to parallelize, but that is
not today.
Remove a leftover variable from a refactor.
Mid work.
Make use of new default parameter distributions.
Update stochastic generation scripts

Coopr changed their internal API somewhat recently so update
accordingly.

Was similarly playing a little fast and loose with "zero" values of
parameters, so this updates the script to be a little more robust.
Rework pformat_results for speed.

With larger models, pformat results was feeling some inefficiencies.
This implementation no longer goes back to the Pyomo model, but instead
directly uses the returned results.  For the time being, since we only
care about the variable values, this is appropriate.  At the point we
need more information reported, I'll update this code.

Meanwhile, it's pertinent to note that this code is technically not
robust, given the line that removes single quotes:

 ... name.replace("'", '') ...

The implicit assumption is that variable indices will not have single
quotes in them.  I believe this to be safe because the Pyomo AMPL data
file parser does not accept them, nor do I know if the AMPL data format
even allows them.  However, from a pure Python perspective, a single
quote is a perfectly acceptable as an index.  Thus, this is safe within
the context of Coopr, but not in a general computing sense.
Update a validation error message.
Implement more "Default" parameters.

Looking at just temoa_island.dat, for our modeling purposes, there are a
number of repeated datum elements in CostFixed and CostMarginal.  This
change allows a modeler to define default fixed and marginal costs per
vintage of a technology, such that as long as that process is alive, it
will cost the same (in nominal dollars).  This still affords the modeler
the ability to override any default if they so choose.

New parameters:

CostFixedVintageDefault
CostMarginalVintageDefault
Use BuildAction in place of "empty-Set" hacks.

When I first implemented these sanity checks, I was unaware of Pyomo's
BuildAction capability.  In looking at the commit logs, it appears Pyomo
/did/ have them, so shame on me.

Meanwhile, this amounts to an NFC in that the sole difference is the
lack of storage of an empty set or tuple per check.  Oh boy.  But this
is semantically better so I use it.
Merge branch 'how_many_stages' into tmp_expected_cost_guessing

Conflicts:
	temoa_model/pformat_results.py  (resolved)
	temoa_model/temoa_model.py      (resolved)
Ensure that only one copy of variables mentioned

This is not a big deal, but it reduces PySP complaining.  Also means a
slightly smaller file.  Whoop de doop.

Also, preparing to individually specify future constraints from here on
out.  Hence the commented out line.  Will need to clean that up in the
future.
A finally working ECIU.

Also note that what we were calling "Expected Cost of Guessing" has
already -- and more accurately -- been called expected cost of ignoring
uncertainty.

This implementation is substantially cleaner.  Next step:
multiprocessing!
Remove differential of CapInvest and CapFixed.

I still like the idea of being completely transparent about where a
value comes from, but I think this particular transparent request would
be better served by the post-processing script that we /really/ need to
create (that would generally take care of AddReportingVariables).
The next round of the ECIU implementation.

The previous commit worked, but was only single-threaded.  This enables
multiprocessing, but yet only for a single box.

Solving the ECIU set of a stochastic problem is currently implemented as
a recursive algorithm.  Stage 1 is solved for each assumption, and then
stage 2 is solved for each prior assumption and each assumption.  Then
stage 3, and so on.  This is currently a naïve implementation that uses
parallelism, and is a rough approximation of a breadth-first search.

Of note, the parallelism is somewhat poorly handled in the script,
mainly because I need to learn some of the esoterics of the Python API.
The number of concurrent jobs allowed is 1.5 times the number of cores.
So for Cygnus, where each node has 8 processors, this script allows 12
concurrent solves.

I believe this implementation to be portable to Windows, though I do not
know how comparatively efficient Windows would be given the expense of
creating new processes.

Next steps of implementation:
  - Allow master to be a "passthrough" to disk.  Currently, the master
    process stores the variables for each solve in memory.  This gets
    unwieldy fairly quickly, and at only 5 stages for the simple Temoa
    Island, our 16 GiB is not enough.  One step to solving this would be
    to convert the algorithm into a depth-first search.  Then, only the
    minimal slice of solutions would need to be actively present in
    memory at any point in time.

  - Checkpointing.  Given long running iterations, it is more than
    conceivable that something could break mid-solve.  Thus, having
    checkpoints automatically enabled would be a very nice addition,
    especially in preparation for the next item:

  - Enable computation on the entire cluster.  As noted above, the
    current implementation is limited to a single machine.  We have a
    cluster, and next need to use it.  I imagine this would be
    done by sub-masters on each node, and passing information back to
    the "passthrough" master instance.