The last of a series of recent patches to address performance
degradation from the introduction of the LTMSiebar. This last
patch introduces a CPX aggregates cache to re-use aggregated
CPX data (e.g. for plotting a specific season or date range).
The cache is set to only hold 25 caches, which should be enough
for most folks list of seasons. But won't get unwieldy if they
scroll around in the diary view.
The following will be introduced in the last patch of
this series:
1. Introduce 'events' within a season and plot them on the
LTM chart -- a form of 'annotation' but also the beginning
of planned events in the future too.
2. Implement click functionality on LTM charts but decide if
we use click to annotate or to define a new date range or
both?
Last part of the search/filter functionality;
* SearchBox now incorporates filter and search
with a new widget. We can update this widget
to include more fancy UI/Interactions without
having to change the ride list or charts etc.
* Added search/filter widget to the relevant charts
and screens; Metrics, TreeMap, CP, Histogram,
Activity Log, Ride list (refactored out of MainWindow)
* Added namedsearches.xml and adding/selecting them
from a drop down menu on the search box.
* Fixed some performance bugs related to duplicate
signals and redraw/reprocessing. Also ensured that
CLucene remains optional -- but means no search or
filter functionality unless it is available.
When the samples in a ride file start from a large offset
e.g. 6hrs is the timestamp for the first sample. The
ridefilecache will compute bests over the initial 6hr
gap.
This patch adjusts the timestamps so they always start
from zero, but only when calculating bests -- it does not
modify the ride data.
We may want to consider 'automatically' fixing this during
ridefile reading, but for now this fixes a nasty bug that
causes GC to hog CPU for large periods of time when computing
the cache.
Fixes#510.
Very basic start, this will now let you plot
VAM on the CP curve. VAM is a measure of climbing
speed and for comparative purposes should be
normalised to the slope climbed.
In this first pass of implementation the VAM metric
is not normalised in any way. It merely represents
the climbing rate, in meters per hour, that was
sustained over each time interval from 5mins to the
ride duration.
If the ride is undulating then only ascension is
included, any time on the flat or descending is
included but meters climbed will be zero. This is
akin to the way we handle power where we include time
when freewheeling.
More sophistication is needed, especially normalising
the value to a common gradient (e.g. 10%). But this
will prove challenging when VAM is comprised of
undulating elements (i.e. gradient is cumulatively
zero, but could contain segments with steep parts).
It may be more appropriate to only measure VAM for
sustained climbing i.e. ignore ride sections when
descending or on the flat.
More thought needed.
Fixes#414.
This is a fix for bug 205 which is registered against v2.1 but
is also present in v3. This fix will not be relevant for v2.1
since the cpi file has been replaced with the cpx file.
Lots of nitty fixups, largely for uninitialised temporary
variables.
I have left the use of boost::function and boost::bind in the
DownloadRideDialog alone, so it will vomit when compiled
with boost 1.46 and gcc 4.5 or higher. Will look into this
more carefully at a later stage.
I am working up to resolving issues identified from -pedantic next.
Mark Rages has developed a super fast and innovative
approach to identifying max-mean intervals. This
approach is 20% faster than the current approach and
importantly does not require "downsampling" of data
yielding much higher resolution for longer intervals.
The code has not been 'adjusted' to adopt QT style
containers (e.g. QVector) and uses malloc/free.
The primary innovations include:
* integrating the data series to reduce the operation
for identifying an interval sum to a single subtract
operation.
* Searching for max sum via a window-search rather
than iterating over the entire series (divide / conquer)
Interestingly, now we have retained high resolution the
xPower algorithm still yields differing results to the
existing metric code. I have contacted Sean to get some
insight into why this might be the case, but suspect it
is related to the implementation of the xPower 25s EWMA.
Tip o' the hat to Mark Rages for this -- sometimes you
just have to accept that no matter how smart you think
you are, there are some folk who /really are/ smart!
The .cpx file used unsigned long to reduce storage
requirements but lost precision. This patch migrates
to using floats, which in most cases are the same size.
One side effect of this update is that mean-max charts
for HR, Speed, Cadence no longer have a 'staircase' effect
and plot more smoothly.
The recent update to plot histograms for seasons or other
date ranges did not support displaying by zone since the
cache did not contain zoned data. This patch fixes that
with an update to RideFileCache to pre-compute and to the
PowerHist class to retrieve and plot.
There are some minor issues that need to be addressed:
* Handling aggregation with different zone schemes
* Deciding which zone scheme to use for the bar labels
when multiple differing schemes have been used within
the date range selected.
* Showing a break down of time in zone by range i.e.
how much time was spent at Threshold when CP was X
as opposed to when it was Y (hint: do it like we
currently display intervals when plotting a single
ride).
* Refreshing the Time In Zone data in the .cpx file
when CP/LTHR changes is not implemented.
The RideFileCache now checks the version of the cache to
determine if it needs to be refreshed -- so no need to
delete old .cpx files before running GC with this patch.
The recent RideFileCache patches added functions to
pre-compute mean-max and distributions. This enabled
this patch to add plotting histograms for a date
range rather than a specific ride.
It supports all the same data series as before but will
allow you to select a season from a new combo box.
I have refactored a fair amount of the code, but kept the
original code in PowerHist as close to unchanged as I could
since I did not want to disturb existing functionality.
There is no support for Zoning historic data -- this requires
an update to the RideFileCache.
The metric code for calculating NP was sub-optimal (actually
it was pretty crap). This patch improves the performance of
the calculation quite substantially (>50% improved).
Additionally, the critical durations code has been adjusted
to reduce the amount of work for long rides (>3hrs or more).
The Skiba and Coggan metrics for xPower and NP
respectively can now be plotted on the CP curve.
There are two issues;
* Downsampling of data to 5s samples skews xPower's EWMA
* Setting scale to start at 30mins breaks the x-axis scale engine
Both issues need fixing, since the first skews xPower upwards and
the second suggests that xPower/NP are meaningful for durations
less than 30 minutes.
Fixes#307.
Peak 1s - 5s critical heartrate was way off the charts and did
not represent the data within the ride file.
Almost certainly caused by the WKO+ file importer, or possibly
by the WKO+ files themselves. It is possible to have ride files
with samples that are shorter than recIntSecs, e.g. where the
recording sample rate is 1s you might see:
Time HR
01:21:32.0 157
01:21:32.7 157
01:21:33.0 157
In this case there are two samples between 1:21:32 and 1:21:33 rather
than the expected one sample. The code to compute averages used the
duration and recIntSecs to determine the average. This patch now
maintains a count instead.
Fixes#319
Many thanks to Gary Smith for helping to diagnose and fix
this error. It is caused by ridefiles that have a gap in
recording at the very start of the ride (i.e. the first
sample is > recIntSecs).
Hopefully this means the CP code is now robust. It is also
worth noting that after fixing the erroneous copy/paste
code in compute() it is now 5 times faster than the original
code and computes 5 times more data series.
Fixes#316.
The new implementation of CP calculation uses a different
approach to identifying critical power/cadence etc which
makes it sensitive to gaps in recording (it assumes all
samples are temporally contiguous).
This patch ensures the data series are pre-processed to
add 0 values for any gaps in recording -- it does NOT
try to smooth data, since there are tools available to
do this, and if the data as presented has gaps we will
not attempt to 'correct' them -- the user can do this
themselves.
It leaves ride data intact.
Fixes SEGV in RideFileCache caused by incorrect recIntSecs setting
for a ridefile. Other reported issues with high power values for
short intervals was data related and not a bug.
Fixes#314.
