[Kst] RE: Kst - parameter lists and events

[Andrew Walker]

Right, I think we're now almost on the same page.

I would rather put the parameter name information in the
code as for some of the fits the number of parameters
is variable, and it is easier to handle this in code
rather than xml. Also, if we use the code we can (maybe)
later add translation.

Unless I hear any other complaints I'll assume everyone is
happy with this and start coding it up.

Andrew

-----Original Message-----
From: Barth Netterfield [mailto:netterfield at astro.utoronto.ca]
Sent: Friday, July 16, 2004 12:34 PM
To: Andrew Walker
Cc: kst at kde.org
Subject: Re: Kst - parameter lists and events


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