Skip to main content

Hey!

In our tooling for Power Analysts we compute synthetic-timeseries for them to evaluate scenarios of flow exceeding a threshold  value.

     In the current implementation of  SyntheticTimeseries only Average and Interpolation aggregates are allowed. This leads to scenarios where zoomed out (and down-sampled) views of data computed through the SyntheticTimeseries API displays non-informative values. Consider the example below, where the top image is the un-aggregated addition of two timeseries, and the bottom is with the use of SyntheticTimeseries.

 

 

The post wasn’t so clear about the problem:

  • The amplitude of the signals are different enough that it might sway the analysis.
  • The amount of data is such that we have to use aggregation, a couple of million datapoints.
  • We hold the amount of data-points constant in the bottom view, such that if the user would zoom to a peak, it would resolve closer to what’s shown in the uppermost plot. 

Thank you for a great question!
Unfortunately, in synthetic time series, we currently only support average and interpolation averages. With average, you only get the bottom graph, which does not capture the variation in the input data. With interpolation, you would get random fluctuations around the average.

In your case, the best solution would likely be to have two graphs, one where you use the max aggregate and one where you use the min aggregate. I have added it to the todo list for synthetic time series!

Would it be possible to let normal and syntetic time-series share the same back-end, but that syntetic time-series have a time-to-live field, e.g. default set to 1h. In the example, after 1 hour the syntectic times-series is automatically deleted. Then we would have the min and max generated for us ( maybe not fast enough, but possible to fix?) and we could use the syntetic time-seres just like the normal ones.   

Would it be possible to let normal and syntetic time-series share the same back-end, but that syntetic time-series have a time-to-live field, e.g. default set to 1h. In the example, after 1 hour the syntectic times-series is automatically deleted.

 

Currently all synthetic time series use the normal backend, and calculate on the fly. We have considered persistent synthetic time series, where we store synthetic data points back to a normal time series. We still have plans for it, but it is not top priority.


Then we would have the min and max generated for us ( maybe not fast enough, but possible to fix?) and we could use the syntetic time-seres just like the normal ones.   

We want to add min and max as aggregates in synthetic time series. Then you’d be able to do things like max(TS1)+max(TS2), where max() denotes a max aggregate. This will be fast, and it’s not a big feature.
What is more tricky is max(TS1+TS2), in which case you’d need persistent synthetic time series or use unaggregated input data. 

Is there any updates on this? Mathias mentioned one year ago about the persistent synthetic timeseries.
It would be very interesting to to be able to combine aggregation and syntheticTimeseries

Unfortunately, persistent synthetic time series hasn’t made it to the list of things we have the capacity to work on yet, nor has it made it onto the official roadmap (I.e not in the cards right now for the next ~12 months).

Reply


Terms & ConditionsCookie Settings