Minimum capacity build constraint

[bmaluenda]

This includes binary variables into the model, so solution time is increased significantly because now the solver needs to branch and bound. Hence, I included it as a separate module, so users can turn this constraint "on and off" according to their simulation needs. Comes with an example. Also added a tiny description to the README file of the discrete_build example, so differences are more noticeable to a new user.

[josiahjohnston]

Thanks for implementing this!

I think we can leave it in the main project/build.py file though. Users can already enable or disable this feature by specifying data for g_min_build_capacity, so pushing the model components into a separate module seems extraneous.

If the g_min_build_capacity parameter is set to 0 for all projects, then no binary decisions will actually be defined since NEW_PROJ_WITH_MIN_BUILD_YEARS will be an empty set.

Minor point: for Enforce_Min_Build_Upper, you could use:

        ...
        sum(m.lz_total_demand_in_period_mwh[lz, p]
                for lz in m.LOAD_ZONES)))

[bmaluenda]

You are right, these constraints may be managed through parameter input. Implemented the requested changes.

[josiahjohnston]

Looks good to me!

[josiahjohnston]

Just caught a bug: A dangling reference to the project.min_build module in examples/discrete_and_min_build causes the tests to fail.

I tried removing that module, then it complains about the objective function value not matching.

[bmaluenda]

After removing that reference, I re-ran the example and found something interesting: if the upper bound on BuildProj is too big, then the constraint is not properly enforced. As of now, the constraint is ignored and the model builds 3 MW of the NG_CC project on 2020. When I manually overwrite the upper bound to an arbitrary, but small number (m.BuildProj[proj, p] <= m.ProjCommitToMinBuild[proj, p] * 10), then the model behaves as expected and builds the minimum of 5 MW. This probably has to do with a numeric problem, where the rounding errors make the BuildProj variable look like a 0 in that constraint, since the right hand side is an enormous number compared to it (maybe it has something to do with the 'scaling' warnings Gurobi was hinting?).

I'm not sure on how to deal with this. A simple and workable option would be to create a new g_max_build_capacity parameter for each gen_tech and set it at the right hand side of the Enforce_Min_Build_Upper constraint. Another option is to set the upper bound at a more reasonable value. For now it is set as the sum of all energy that is consumed throughout the simulation.

[josiahjohnston]

Interesting. Seems to be restricted to glpk

$ cd examples/discrete_and_min_build
$ python -m switch_mod.solve --solver=cplex; cat outputs/total_cost.txt 
23382244.324
$ python -m switch_mod.solve --solver=cbc; cat outputs/total_cost.txt 
23382244.2373
$ python -m switch_mod.solve --solver=glpk; cat outputs/total_cost.txt 
21711432.5137

[josiahjohnston]

I posted a patch to #64 that removes the dangling reference and fixes the weird glpk behavior. Can you review it @bmaluenda?