Open ojdo opened 8 years ago
Hey @ojdo,
This would be a welcome addition.
For a short name, I might suggest pyomoio.py
. I'm happy to adopt pandas
(and xarray
) as the primary in-memory representation of data. We can then develop a number of backends. I know that @danielhuppmann is interested in a SQL-based backend as well.
Why don't we target the canonical transport problem (lacking a link, but it's the canning problem in the US I believe) as a test instance for I/O. We could use it for multiple backends.
Cheers, Matt
I second pyomoio.py
.
A generic pyomo problem sounds useful, and could be re-used even beyond I/O.
In order to actually solve, we need at least GLPK. To get that running easily across platforms, I think we should use conda. Thanks to the relatively new conda-forge channel, which already includes cross-platform builds for both pyomo and GLPK, we could install all requirements for all platforms using just a requirements.yml
file.
Before I dive into porting pandaspyomo.py to the toolchest, I wanted to collect opinions on some topics. In a nutshell, it allows to read out variables of arbitrary dimensionality to a DataFrame with a suitably sized MultiIndex.
Name
I came up with
pandaspyomo
because of obvious reasons, but would be happy with a shorter, catchier name. Ideas?Tests
The minimum viable strategy I see now is to create at least one (trivial) toy problem in Pyomo, let it solve with GLPK, load the result, and then use this primed model object as my test object. But still, this would be a >20 LOC setup for a series of simple
list_entities
andget_entity
calls.I would encapsulate that setup in a function and call it in each of the tests separately, so that there is no coupling between the tests. Any thoughts on that?