|
Back
Midas
Rome
Roody
Rootana
|
Midas DAQ System |
Not logged in |
|
|
28 Aug 2019, Nick Hastings, Forum, History plot problems for frontend with multiple indicies
|
28 Aug 2019, Stefan Ritt, Forum, History plot problems for frontend with multiple indicies
|
28 Aug 2019, Nick Hastings, Forum, History plot problems for frontend with multiple indicies
|
28 Aug 2019, lcp, Forum, History plot problems for frontend with multiple indicies
|
16 Sep 2019, Konstantin Olchanski, Forum, History plot problems for frontend with multiple indicies
|
16 Sep 2019, Konstantin Olchanski, Forum, History plot problems for frontend with multiple indicies
|
29 Aug 2019, Ben Smith, Forum, History plot problems for frontend with multiple indicies
|
01 Sep 2019, Nick Hastings, Forum, History plot problems for frontend with multiple indicies
|
16 Sep 2019, Konstantin Olchanski, Forum, History plot problems for frontend with multiple indicies
|
16 Sep 2019, Nick Hastings, Forum, History plot problems for frontend with multiple indicies
|
17 Sep 2019, Konstantin Olchanski, Forum, History plot problems for frontend with multiple indicies
|
18 Sep 2019, Nick Hastings, Forum, History plot problems for frontend with multiple indicies
|
27 Sep 2019, Konstantin Olchanski, Forum, History plot problems for frontend with multiple indicies
|
24 Aug 2020, Konstantin Olchanski, Forum, History plot problems for frontend with multiple indicies
|
|
Message ID: 1986
Entry time: 24 Aug 2020
In reply to: 1710
|
Author: |
Konstantin Olchanski |
Topic: |
Forum |
Subject: |
History plot problems for frontend with multiple indicies |
|
|
This turned out to be a tricky problem. I am adding a warning about it in mlogger. This should go into midas-
2020-07. Closing bug #193. K.O.
> We should fix this for midas-2019-10.
>
> https://bitbucket.org/tmidas/midas/issues/193/confusion-in-history-event-ids
>
> K.O.
>
>
>
>
>
> > Hi Konstantin,
> >
> > > > [local:e666:S]History>ls -l /History/Events
> > > > Key name Type #Val Size Last Opn Mode Value
> > > > ---------------------------------------------------------------------------
> > > > 1 STRING 1 10 2m 0 RWD FeDummy02
> > > > 0 STRING 1 16 2m 0 RWD Run transitions
> > >
> > > Something is very broken. There should be more entries here, at least
> > > there should be entries for "FeDummy01" and usually there is also an entry
> > > for "FeDummy" because one invariably runs fedummy without "-i" at least once.
> >
> > This is a fresh experiment that I started just to test this this issue, that is why there are not many
> > entries in /History/Events. I agree though that we should expect to see a FeDummy01 entry.
> >
> > > The fact that changing from "midas" storage to "file" storage makes no difference
> > > also indicates that something is very broken.
> > >
> > > I want to debug this.
> > >
> > > Since you tried the "file" storage, can you send me the output of "ls -l mhf*.dat" in the directory
> > > with the history files? (it should have the "*.hst" files from the "midas" storage and "mhf*.dat"
> > files
> > > from the "file" storage.
> >
> > When I started this experiment yesterday(?) I disabled the Midas history when I enbled the file
> > history. Jsut now I reenabled the Midas history, so they are currently both active.
> >
> > % ls -l work/online/{*.hst,mhf*.dat}
> > -rw-r--r-- 1 hastings hastings 14996 Sep 17 10:21 work/online/190917.hst
> > -rw-r--r-- 1 hastings hastings 3292 Sep 18 16:29 work/online/190918.hst
> > -rw-r--r-- 1 hastings hastings 867288 Sep 18 16:29 work/online/mhf_1568683062_20190917_fedummy01.dat
> > -rw-r--r-- 1 hastings hastings 867288 Sep 18 16:29 work/online/mhf_1568683062_20190917_fedummy02.dat
> > -rw-r--r-- 1 hastings hastings 166 Sep 17 10:17
> > work/online/mhf_1568683062_20190917_run_transitions.dat
> >
> > And again, just as a sanity check:
> >
> > % odbedit -c 'ls -l /History/Events'
> > Key name Type #Val Size Last Opn Mode Value
> > ---------------------------------------------------------------------------
> > 1 STRING 1 10 1m 0 RWD FeDummy02
> > 0 STRING 1 16 1m 0 RWD Run transitions
> >
> > Regards,
> >
> > Nick. |