Partition duration for time structures

[JulStraus]

This is a first take on including partitions based on the duration of operational periods as outlined in #94. There are a few things to highlight:

The introduction of the PartitionDuration abstract type enables

• the introduction of time profiles indexed over the partition,
• the utilization of existing time profiles for indexing, and
• simplified indexing of variables (easier to identify the corresponding partition).

However, it requires the introduction of subtypes for all potential combinations. This is a bit annoying, but does not require to much work either.

There are still a few open questions:

1. Shall we allow for varying durations of the partitions? I personally think yes as a partition could be, e.g., 5 days and 2 days to differentiate between work week days and weekend days. The implementation should be straight forward.
2. The last partition can be in the current stage shorter than specified. The reason is that we do not know a priori a) how many partitions are available and how many time periods are in the last partition.

My plan is now to

1. incorporate profile indexing and
2. introduce all other subtypes that are required.

Important

I consider partitions only to be relevant for operational periods. The reason is that it does not make sense, at least in my opinion, to have partitions of operational scenarios. It could theoretically make sense for representative periods or strategic periods, but I think it is better to not allow for it at the current stage.

[JulStraus]

I added now support for most of the available time structures, excluding TwoLevelTree, SimpleTimes, and CalendarTimes. TwoLevelTree is something which I want to add in a different PR. In addition, I also want to add in a different PR the potential for specifying explicitly the minimum duration of each partition.

[Copilot]

Pull request overview

Introduces duration-based partitioning for operational time structures, enabling profiles and variable indexing over these partitions (per #94).

Changes:

• Added partition_duration and supporting PartitionDuration* types/iterators to generate non-overlapping duration-based partitions.
• Introduced PartitionProfile and extended profile indexing/arithmetic to support partition-based indices.
• Added extensive tests and updated API reference docs for the new functionality.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
src/utils.jl	Adds PartitionDuration abstractions and the core partition_duration iterator implementation.
src/partitions/strat_periods.jl	Implements partition types and higher-level partition generation for strategic/two-level structures.
src/partitions/rep_periods.jl	Implements partition types and higher-level partition generation for representative periods (incl. nested scenarios).
src/partitions/opscenarios.jl	Implements partition types and higher-level partition generation for operational scenarios.
src/profiles.jl	Adds PartitionProfile and enables profile indexing via PartitionDuration indices; adds arithmetic overloads.
src/TimeStruct.jl	Includes new partition source files and exports PartitionProfile / partition_duration.
test/runtests.jl	Adds test coverage for partition/profile indexing behavior and partition iterator invariants.
docs/src/reference/api.md	Documents partition_duration and PartitionProfile in the API reference.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[trulsf]

Looks good to me. Maybe fix some of the comment typos identified by Copilot (other comments seem not that relevant).

[JulStraus]

I did a minor additional naming change @trulsf . Let me know if you are ok with it and I will merge it afterwards.

[trulsf]

I think the new name is better so just go ahead with the merge - after a minor format fix :)

[JulStraus]

I think the new name is better so just go ahead with the merge - after a minor format fix :)

Interestingly, the local formatter (v2.6.11 compared to v2.8.5) considered it to be formatted... I see the return with a throw statement slightly critical and stupid as in my opinion, there should not be a return of a throw statement as it automatically breaks the code anyhow.