Comparison of list of runs between RCDB, analysis launch, and random triggers

[Hao Li]

Dear experts,

I am investigating how well my simulation matches real data in a run-by-run sense,

and I am confused as the number of runs doesn't match:

For low E runs (51384-51457):

1. # of skims (analysis launch analysis-2018_01-ver05) = 48
2. # of runs (using rcdb query "@is_2018production and @status_approved" for run51384-51457) = 47
3. # of random triggers (/w/osgpool-sciwork18/halld/random_triggers/recon-2018_08-ver02/) = 46

Specifically, the difference between item 1 and item2 is run51426 which I don't see anything wrong with?
In addition, the difference between item 1 and item 3 is run51427&run51396, who do have a weird flag, "is_valid_run_end=False".

I am also looking at the fall 2018 dataset excluding the low energy runs, where the similar discrepancy appears as well. Most of the difference is due to the flag "is_valid_run_end=False", too. But there are quite a few cases the same as the comparison between item 1 and item 2 above, too.

Could anyone explain the function of this flag to me? It seems to make a difference in selecting runs. But I don't see anything wrong with the skims labeled "False" so far. And I haven't seen anyone using this flag to select runs in their RCDB queries on MCWrapper's dashboard...

Cheers,

Hao Li

[Naomi Jarvis]

I think the valid end run flag is set to false if the DAQ does not complete the end of run actions properly, eg if it crashes before the run ends.

Naomi.

--
You received this message because you are subscribed to the Google Groups "GlueX Software Help" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gluex-softwar...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gluex-software/CAHdZdSkaSOD%2BMVMNTNLy3g6tMYhrwKAQ1hMiGud7-siZwuwbMg%40mail.gmail.com.

[Hao Li]

Thanks! Is that the reason why there is no random triggers for those runs? I

If so, do you still want to keep those runs in your cross section calculation?

To view this discussion on the web visit https://groups.google.com/d/msgid/gluex-software/CAP2LRLjPH-BSzdUvOzzR5YvzVNpc1t_5TLrTC3jLCH%2BoBn1uGQ%40mail.gmail.com.

[Alexander Austregesilo]

Dear Hao,

Indeed, no random trigger skims were created for the runs 51396 and 51427. When this happened in the past, we used the PS trigger to mimic the rate effect in MC. We should probably do that for these two runs as well to rule out any systematic effects in the cross section calculations.

I don't know why the run 51426 apparently passed the rcdb query when it was reconstructed, but does not any more. This could be a mistake.

Cheers,

Alex

To view this discussion on the web visit https://groups.google.com/d/msgid/gluex-software/CAHdZdSmEQ8%2Bu_FhUDcZLQCzXEBv68R6M1tXj3nLLa09rg1HU7g%40mail.gmail.com.

[Dmitry Romanov]

Hi Hao,

 

Let me clarify how RCDB works, what is this flag and how it might affect things.

 

1. During the run, RCDB run update scripts every several minutes updating/overriding values
2. Daq calls RCDB (the same script) and identifies the reason for the update. There are 3 reasons DAQ calls RCDB for an update:
1. run-start,
2. run-update (every several minutes during the run),
3. run-end
3. On run-start many values which will not be changing during the run are filled
4. run-updates and run-end are absolutely identical with the only difference that on run-end "is_valid_run_end=True" and on the regular update "is_valid_run_end=False".
5. Actually we could live with only run-start and run-end to fill RCDB but because CODA can crash or something may go wrong with the DAQ at the end, we do those several minutes updates, so if the DAQ crashes we would have the updated data in RCDB and this data is taken no longer than several minutes before the crash.
6. So. "is_valid_run_end=False" means that the DAQ crashed (or killed) and the last updates in RCDB where made several minutes before the actual stop. But all data taken during run is should be normal, this flag doesn’t indicate anything related to this.

 

If you are comparing data using aliases like @is_2018production I think it would be helpful to know how those aliases correspond to values in RCDB:

https://github.com/JeffersonLab/rcdb/blob/master/python/rcdb/alias.py

Please, let me know if you have more RCDB related questions. You may also find me on our Slack

 

Kind regards,

Dmitry

To view this discussion on the web visit https://groups.google.com/d/msgid/gluex-software/CAP2LRLjPH-BSzdUvOzzR5YvzVNpc1t_5TLrTC3jLCH%2BoBn1uGQ%40mail.gmail.com.

[Hao Li]

Hi Alex,

I just dug a little bit, and I found out that Run51426 didn't pass because in the alias "@is_2018production and @status_approved" there is one condition requires that "event_count > 10000000".

For the missing random triggers in fall 2018, do you know if there is already a plan to do the same as in the past, i.e. useing the PS trigger to mimic the rate effect in MC? If not, who should I talk to about this?

Cheers,

Hao

[Hao Li]

Hi Dmitry,

Thanks for explaining the RCDB procedures! 

One more question, is there a proper way to exclude the low energy runs in the RCDB query? One suggestion I got from last year was to split the fall 2018 run period into two batches. Could there be a new alias been added to include some filters to exclude the low energy runs specifically by, for example, the position of the coherent peak, or more directly by excluding the run numbers from 51384-51457?

Cheers,

Hao

[Richard Jones]

Hello Hao,

Whatever may be the current practice of what to do when random trigger skims are not available for a particular run, please be aware that the PS triggers are not a true substitute for random triggers. They are not statistically equivalent, and should not be mixed up with actual random triggers in a multirun analysis that relies on them measuring the same thing. They don't.

-Richard Jones

On Thu, Sep 17, 2020 at 12:35 PM Hao Li <h...@andrew.cmu.edu> wrote:

[Mark-Macrae Dalton]

Hi Richard,

Could you be more explicit about what the actual problem is and what concrete effects it would have?  I believe that we already do this and we should evaluate whether this is worse that alternatives like not including that particular run in the simulation.

Best,

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/gluex-software/CABfxa3SUDPsYBp7fE1nh7Pw8ZDvzW8PdVzi70m%3DGhn4axJrTDw%40mail.gmail.com.

[Sean Dobbs]

Hi Hao,

Let me try to close some loops here:

- I think the status of Run 51426 is clear, and for consistency we
should use the current output of "@is_2018production and
@status_approved".

- For the runs missing random triggers, I was tracking down some
similar problems in Spring 2018 data, and it seems like the problems
are due to some values used in the beam current fiducial cuts not
being filled properly. This issue is probably linked to the improper
termination of the run. So, I'll check each of these runs
individually to be sure, but from the handful that I saw, the beam-off
periods that we try to exclude when creating the random trigger files
are a very small part of the run, so including them should be a
negligible effect. The plan is to try making the random trigger files
without the beam fiducial cut, then. It will be helpful to know if
there are any other such runs in the Fall 2018 data (I think we have
the Spring 2018 data covered).

This shouldn't be a problem going forward since we're in the process
of switching to a different scheme for implementing this fiducial cut.
Once we have that working, it might make sense to make another set of
random trigger files for previous data sets, but again this isshould
be a really minor correction.

- To select the "low energy" runs from the "high energy" runs in 2018
(the electron beam energies were the same, just the PS acceptance was
changed), you can append "and beam_current < 49." to your query to
select the low energy runs - for the high energy runs just switch the
Let me know if that doesn't work.

---Sean

> To view this discussion on the web visit https://groups.google.com/d/msgid/gluex-software/CAHdZdS%3D5mc1XY0%2BwcBPCiGv%3D3iZpbMLWOaft6o6bPoDXkmuyZA%40mail.gmail.com.