Add preference to use the 'optimized with last sample' AA postprocessor - #3915
Add preference to use the 'optimized with last sample' AA postprocessor#3915rjwills28 wants to merge 3 commits into
Conversation
|
jacomago
left a comment
jacomago
left a comment
There was a problem hiding this comment.
Isn't it a bit limiting to make this a configuration parameter rather than replace the 'use_raw' on the trace to be an enum of 'optimized', 'optimizedWithLastSample', 'raw'. Do we really want for every PV optimizedWithLastSample over optimized? Or is it a case by case basis? I always think of a temperature sensor vs switch triggered, one is a continuous value that we sample in time whereas a switch triggered is an event that happens. Those two usually have a different way you want to think about 'last sample' included.
Also optimized is a bad name, we should try avoid keeping it. I think we should consider a better name that describes what it does, displayMinMaxMean or something. 'Optimized' doesn't say what it is optimized for.
| protected void fetchDataInternal(String pvName) throws ArchiverApplianceException { | ||
| String optimized = new StringBuilder().append(ApplianceArchiveReaderConstants.OP_OPTIMIZED) | ||
| String optimizedOperator = ApplianceArchiveReaderConstants.OP_OPTIMIZED; | ||
| if (AppliancePreferences.ppOptimizedWithLastSample) |
There was a problem hiding this comment.
switch maybe makes more sense
| @@ -20,6 +20,7 @@ public class AppliancePreferences { | |||
| @Preference static boolean useStatisticsForOptimizedData; | |||
| @Preference static boolean useNewOptimizedOperator; | |||
There was a problem hiding this comment.
Shouldn't we instead be changing this to an enum?
2 participants
A while back we introduced a new post processor to the Archive Appliance that better represents the data called 'Optimized with last sample'.
The history and detailed discussion of why this pp was required is here: ControlSystemStudio/cs-studio#2483.
In brief, say a PV has a flurry of activity, then goes to a value (say 0) and does not change for some time. With the Optimized PP, you would get the average during this flurry, say 50 and then the next bins will have no events, in which case the Optimized algorithm just returns the mean value of the last bin that had events, e.g. it would return 50. This means that data browser would show the value '50' for the entire duration that the PV does not change, even though the PV's last value was 0.
The optimized with last sample algorithm is based on the optimized one but if a bin does not have any events then it uses the last value in the previous bin that had events and hence in this example would return 0 as desired.
This new post processor was introduce to the CS-Studio data browser as a preference that could be switched on. In this PR I have added a similar preference to use the
optimLastSample_option.At the moment I have left the default as 'false', i.e. it is not used but I wonder, given that this post processor gives a better representation of the data, whether it should be the default to use (i.e. make the variable true) - thoughts?
Checklist
Testing:
Documentation: