[Kst] Re: Kst - parameter lists and events

[Barth Netterfield]

Parameter lists:

OK.  I talked your intended behavior over w/ some of the other users, and I 
think your plan has the correct behavior from a user point of view, assuming 
I understand it:  I think you mean:
	-Plugins can have vectors which are marked in the XML as being parameter 
lists
	-These vectors are created to not export statistics scalars by default, but 
are otherwise vectors like any other, and show up in all vector lists, etc.
	-The plugin (or the XML?) has encoded a string description for each element 
of the pvector.
	-KstPlugin can use these names to produce parameter scalars (whether it does 
should be user selectable in the plugin and fit dialogs?)
	-The fit dialog can use all this to make and install a default label which 
refers to the parameters by their scalar name.

Is this correct?  If so, I am happy. 

other suggestions: 
-If you are going to do this, I think that a vector being able to be a 
parameter list should be a property of all plugins, not just fits (eg, it 
would be 'just the thing' for the statistics plugin, etc).

-Avoid changes to vectors and scalars. They shouldn't be needed.

George, Rick, do you have thoughts?

EVENT MONITORS
>
> I feel that the event monitor should not look at old values.
> Many of the events will be triggered within a specific
> context (i.e. value greater than 3 sigma above the mean).
> Thus, whether or not an event is triggered depends on whether
> it is evaluated when it comes in or for historical data.

ACK!
Then what is done when you re-load a kst file with an event in it?  How is 
this different than the first time you create and event.

I guess this is the issue:
If events are recalculated each update only on currently loaded data then 
re-loading the same frame range always gives the same event, BUT: if, eg, the 
rms of data is changing as data is coming in then an event which existed at 
frame 900 when frames 0-1000 were being read could disappear when frames 
800-1800 are being read. 

This is neither surprising nor a serious problem when producing event vectors, 
but in deciding if one should send emails or elog entries, we have a major 
conundrum at best!  

Perhaps you are processing last-nights data, and you want to automatically 
produce an elog entry for each [whatever] event.  Then the above is the right 
thing to do. (Unless you load the same data again and produce a duplicate set 
of elog entries)

Or perhaps you are running real time, and only want to send new events.
These events should only be based on currently updating data, and only for 
events that have never been flaged.  

BUT: kst is current data vs historical data agnostic.

My experience with alarms has been that they are really hard to get right, 
even with a stand alone alarm program.  I think that email and elog events 
will be nearly impossible to make generally correct within kst.  Perhaps we 
need a stand-alone?

What is your plan?  (I'm stuck here).

cbn