blue-marble / gridpath

A versatile simulation and optimization platform for power-system planning and operations.
https://www.gridpath.io
Apache License 2.0
95 stars 35 forks source link

Temporal plotting conventions #264

Open anamileva opened 4 years ago

anamileva commented 4 years ago

Transferring some comments from #157 here.

Quoting @gerritdm:

For any temporal plotting, it would be very useful if we can decide on a convention for how to name timepoints/horizons/periods. Right now it seems like we use years (in numbers) for periods, years + horizon number for horizons, and years + horizon + timepoint number for timepoints.

We should either enforce this, and rely on this convention for plotting, or perhaps add some auxiliary columns that make plotting easier so we don't have to use super long timepoint names which makes the axes messy (e.g. we could add a hour_on_horizon column and horizon on period column) or something like that.

Right now my solution has been to use hours on timepoint to calculate the "hours_on_horizon" and use those on axes instead of the full timepoint name.

This could also open a more general discussion on the treatment of all the temporal stuff, which I think is still a little bit confusing with the subproblem/stages layered on top of it. For instance, I think some tables have the subproblem_id added as a primary key unnecessarily, and it's also not 100% clear to me whether timepoints have to be 100% unique, as they are now, or whether they can be the same for each horizon (I think they can be the latter, given the primary key structure).

Related to this: we need to make sure the defaults for subproblems/stages are in line with what's being assumed in the viz suite. Currently the viz suite defaults to subproblem=1 and stage=1 if they are not specified (e.g. when doing capacity expansion). We need to make sure that that is indeed the default value. We can also think about adding an auto-increment to the subproblem/stages to give them an even more standard representation.

anamileva commented 4 years ago

@gerritdm, thoughts on concrete action items from this issue? It's a bit too vague, so I'm inclined to close it.

gerritdm commented 4 years ago

I think concrete actions could be to (note: they are probably separate issues):