[Kst] RE: Kst - parameter lists and events

[Andrew Walker]

I'm reasonably happy with the way things are at present.
One problem we do have is that adding data markers will
not be simple as the events are created on a vector and
not a curve. I'm still pondering this one.

Andrew

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


Any thoughts on the event stuff (below)?

cbn

On July 16, 2004 03:49 pm, you wrote:
> 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