Add dimension groups to TimeSeries for better plots

[tuckermcclure]

Previously, the plot for the IMU measurement time series was useless because too many signals were stacked vertically. This is a draft of the "dimension groups" idea that lets us group dimensions into axes when plotting a time series.

We add a groups section to the VariableDescription, like so:

discrete_outputs = (;
            measurement = VariableDescription{IMUMeasurement}(
                missing;
                title = "IMU Measurement",
                dimensions = [
                    "t" => "s",
                    "delta_theta_x" => "rad",
                    "delta_theta_y" => "rad",
                    "delta_theta_z" => "rad",
                    "delta_v_x" => "m/s",
                    "delta_v_y" => "m/s",
                    "delta_v_z" => "m/s",
                    "delta_t" => "s",
                    "temperature" => "C",
                ],
                groups = [
                    "Delta Theta" => ["delta_theta_x", "delta_theta_y", "delta_theta_z"],
                    "Delta V" => ["delta_v_x", "delta_v_y", "delta_v_z"],
                    "Temperature" => ["temperature"],
                ],
            ),
            ...

and then we get a plot that looks like this:

By default, plots look the same, except that this also changes the default plot style for discrete signals to use scatter! rather than stairs!, so users can clearly see the sample times in a plot. (Also, stairs! very oddly "holds" the right sample between two samples rather than the left, so that for t = [0., 1., 2.], data = [5., 4., 3.], there's a line at 4 from t = 0. to t = 1. This was not expected. I even wonder if it's a bug. There's an option controlling which side of the interval is used for the line between the two, but I think scatter! is more useful anyway.)

This also adds a "matrix" implementation of plot_ts, allowing one to a arrange a bunch of plots in a figure. Here is an example:

The code for this:

# Let's make a little matrix of all of the plots we want.
plot_matrix = Matrix{Any}(undef, 2, 2)
plot_matrix[1, 1] = history["/"]["position"]
plot_matrix[1, 2] = history["/"]["thrust_command"]
plot_matrix[2, 2] = history["/"]["filtered_acceleration"]

# For velocity, we'll combine the truth and the measurement.
plot_matrix[2, 1] = [
    "truth" => history["/"]["velocity"],
    "measured" => history["/"]["velocity_measurement"],
]

# Now we can view that plot.
display(
    SystemsOfSystems.plot_ts(
        plot_matrix;
        figure_kwargs = (; size = (1200, 800)), # Passed along to the figure window.
    ),
)

That's actually a pretty complex plot, because it uses the "truth" vs "measured" behavior for the velocity (which breaks out of the dimension grouping and expands each dimension since the whole point is to show the differences in multiple time series for each dimension). If we didn't need to do that, it gets easier:

display(
    SystemsOfSystems.plot_ts(
        [
            history["/"]["position"]  history["/"]["thrust_command"];
            history["/"]["velocity"]  history["/"]["filtered_acceleration"];
        ];
        figure_kwargs = (; size = (1200, 800)), # Passed along to the figure window.
    ),
)

This PR also reorganizes things so that most of what was in plot_ts is now in plot_ts!, and all plot_ts does is make the figure and link the axes when all is done.

[tuckermcclure]

Turns out I had these as local edits and didn't notice. Then, I had to edit this file (below). I think we should just keep them in this PR.

[tuckermcclure]

I was thinking that we might support history["/aircraft/body:position"] as a shortcut for history["/aircraft/body"]["position"], but that seems really unnecessary. It means that this function sometimes returns a model history and sometimes a time series, and that just makes life complicated. The syntax is already perfectly short.

[tuckermcclure]

By moving the other constructors out of the struct definition, this function is implemented by default, so I could just delete this line.

[Copilot]

Pull request overview

This PR introduces “dimension groups” for TimeSeries so plots can group multiple dimensions onto shared axes (improving readability for high-dimensional signals like IMU measurements). It also expands the plotting API to support in-place plotting (plot_ts!) and composing multiple plots in vertical stacks or matrices.

Changes:

• Add groups metadata to TimeSeries and VariableDescription to control how dimensions map to plot axes.
• Update Makie plotting extension to render grouped axes, change discrete default to scatter!, and add stacked/matrix plot composition helpers.
• Thread groups through log-created TimeSeries objects (BasicLog/HDF5Log) and update tests accordingly.

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 11 comments.

Show a summary per file

File	Description
src/TimeSeries.jl	Adds groups to TimeSeries, keyword constructor, default dimension/group generation, and updated metadata-preserving slicing/resampling.
src/SystemsOfSystems.jl	Extends VariableDescription with groups so log-produced TimeSeries can inherit plotting group metadata.
src/Logs.jl	Passes groups from VariableDescription into TimeSeries created by BasicLog; adds a show method for logs.
ext/SystemsOfSystemsMakieExt/SystemsOfSystemsMakieExt.jl	Implements grouped plotting, new plot_ts! plumbing, discrete scatter rendering, and vector/matrix composition support.
ext/SystemsOfSystemsHDF5Ext/SystemsOfSystemsHDF5Ext.jl	Passes groups into TimeSeries created by HDF5Log (saving/loading groups still TODO).
test/runtests.jl	Updates TimeSeries construction in tests to match the new API.
.gitignore	Ignores .vscode/.

Comments suppressed due to low confidence (1)

test/runtests.jl:32

• TimeSeries is constructed with groups = [], but the groups field is typed as Vector{Pair{String, Vector{String}}}. An untyped empty literal [] is Vector{Any} and will cause a type error at construction. Use a typed empty vector (e.g., Pair{String, Vector{String}}[]) or omit groups to use the default grouping behavior.

    ts = SystemsOfSystems.TimeSeries(;
        title = "Rotor Speed",
        time = collect(0.0:0.1:2.0),
        data = collect(100.0:120.0),
        time_dimension = SystemsOfSystems.Dimension("time", "s"),
        dimensions = [SystemsOfSystems.Dimension("angular speed", "rad/s"),],
        path = "/rotor/omega",
        discrete = false,
    )

---

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

[Copilot]

This call uses keyword-only syntax (TimeSeries(; ...)) but passes bare expressions like ts.title, ts.time_dimension, ts.path, etc. Property accesses are not valid keyword shorthand and this will not parse/compile. Use explicit keywords (e.g., title = ts.title, time_dimension = ts.time_dimension, path = ts.path, groups = ts.groups).

[tuckermcclure]

You are incorrect about this. Property accesses are valid keyword shorthand. E.g., this creates a named tuple called y with a field called a that has the same value as x.a:

x = (; a = 1., )
y = (; x.a, )

There is no need to change this code.

[Copilot]

Same issue here: TimeSeries(; ts.title, ..., ts.groups) is not valid keyword argument syntax and will fail to parse/compile. Switch these to explicit keyword assignments for all non-identifier values.

[Copilot]

Same keyword-argument syntax issue: TimeSeries(; var.title, ..., var.dimensions, ..., var.groups) will not parse. Use explicit keyword assignments for these values.

[Copilot]

When units_are_consistent and first_units is the empty string, the ylabel becomes "<group> ()". Consider omitting the parentheses when units are empty to avoid awkward labels.