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.
I think concrete actions could be to (note: they are probably separate issues):
clarify the documentation on the expected format of the temporal inputs across all the different inputs. E.g. timepoints should be ordered integers, and be unique within a a subproblem (I think?). It would also be useful to provide a set of example input tables with example temporal setups. Once there are more users, a separate tutorial on how to set up different temporal setups could be very useful.
verify that the temporal primary keys and foreign keys in the database are valid
verify that the subproblem and stage are set to 1 if they are not specified by users.
look into using the timestamp column in inputs_temporal_timepoints for the dispatch plots, leveraging built-in date time functionality.
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.