Rethink the way timeslices are specified in input files

[tsmbland]

A few of the input files allow you to specify data at the timeslice level, which all seems to be functional, but it's a bit of a mess and I think we can improve things.

• Preset files (for commodity demands) use an integer to refer to timeslices, which corresponds to the ordering of timeslices as specified in the settings file.
• The technodata timeslices file (for specifying utilization factor and minimum service factor) uses timeslice names, with a column for each timeslice level (e.g. month, day, hour)
• Commodity prices are stored internally at the timeslice level, but as far as I can tell there's no way for users to specify initial commodity prices at the timeslice level. This might be something we should allow.

MUSE also has a timeslice aggregation feature. This allows you to specify groups of timeslices which you can refer to in your input files (only applies to the technodata timeslices file). For example, you could create an "all-day" group, and then for the utilization factor you could have "winter, all-day" = 0.5, "summer, all-day" = 1 etc. This is potentially quite useful, so we should keep this to some extent.

---

Here's what I think we should do:

• I think it's a bad idea to refer to timeslices with integers, so we should change to preset files to use timeslice names
• I think we should have one timeslice column rather than separate month, day, hour columns. You could then refer to a timeslice as "winter.weekend.morning", for example
• Ability to use "ALL" (or similar) to refer to all timeslices at a particular level. For example, you could use "winter.ALL.morning" to apply a utilization factor to both "winter.weekend.morning" and "winter.weekday.morning"
• The timeslice could default to "ALL.ALL.ALL", so that leaving the timeslice column blank applies the parameter to all timeslices.
• I think we need to be careful with demand data. For example, would "winter.weekend.ALL" = 5 mean that the demand in each "winter.weekend" timeslice ("winter.weekend.morning", "winter.weekend.evening" etc.) is 5, or that the sum across all timeslices is 5? I guess the latter makes more sense, but it could get confusing if you have a mix of timeslice-level and aggregated demands in a single file*. So for this reason I might not allow the "ALL" wildcard in this file, or just make sure this point is super clear in the documentation

*To be honest it's confusing anyway because timeslices can have different lengths, so a higher demand value for one timeslice compared to another doesn't necessarily mean that the rate of demand is higher for that timeslice (it could just be that the timeslice is longer).

---

UPDATE
My thoughts on this have changed after #550. Now, I think the only thing that needs doing is to change the preset files to use timeslice names. We don't need "ALL" any more as you can just use a coarser timeslice level for the sector to avoid having to include all the finer timeslices. I also think it's better to have different columns for the timeslice levels, as is currently done.

[martinstringer]

Completely support the proposed solution above.

I guess MUSE would ideally still accept the old format though (so that people's established models will still run). Is it time-consuming/problematic to modify the code to allow both?