Hi Just a follow up.
I ran lrn on 4743 and 4744 for just a few events, I did not see the
"target undefined" warning as indicated by elog messages.
I assume epics target bits are still not read in correctly only that I
disabled those parts of warnings. There were a few inconsistancies
warnings. But they are OK, they happened at refills when epics and scaler
have different speed to response to beam gate. as long as they do not
occur continuously, it is fine.
I also do not see the "physics event earlier than any epics event" warning
up till the 1000th physics event.
I think the situation may be a bug in crunching of an ongoing run. I see
that the crunch of 4744 message came before run 4745. Crunching of an
on going run involves reading chuncks of epics/scaler events the rewind
and process physics events covered by these chuncks. but is suprises me
that it did not complain the same about scaler events. I will take a look
at this.
Chi
On Sat, 14 Feb 2004, Chi Zhang wrote:
>
> Hi Karen and all, sorry for being out of touch since Friday:
>
> > Presumably runs should now be lrn'ed with a -bm +1 argument.
> it is fixed by changing blast:${BLAST_PARAM}/blastrc. now crunching should
> simply be lrn ####
>
> the Wire.Cal now in use may need to be replaced by one that fits inbending
> field better. This one produces resolution almost comparable to 700 series
> last July but may not be the most optimized for inbending.
>
> If we do observe a bad resolution, we need to locate an old Cal file,
> patch it for the added columns of k-factor and per cell resolution.
>
> As for the warnings from lrn: "physics events before any epics events"
> means "physics events before any epics events". So some physics events are
> not bracketed by epics events, the consequence is that some of the run
> conditions for those events(cell temperature for instance) are not known.
> Sometimes it is only because the long time needed to read all epics
> channels after "go" is hit. But event that crashes xcefdmp, I don't know.
>
> but missing epics event is better than missing scaler event in which case
> charge integration is questionable.
>
> Chi
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:30 EST