[Kst] RE: Kst - parameter lists and events

Andrew Walker arwalker at sumusltd.com
Fri Jul 16 22:07:32 CEST 2004

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.


-----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)?


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
> 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
> 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?
> > 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
> 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
> need a stand-alone?
> What is your plan?  (I'm stuck here).
> cbn

More information about the Kst mailing list