Background Interleave Prospects

1

• Background Interleave Prospects
• Richard Dubois
• The problem
• Some numerology
• Simple proposal
• Questions that came up along the way
• w/discussions with Julie Leon

2
The Problem

• We need to generate the full background rate to
  see what gets through the Onboard Filter
• 25 kHz of input from backgrounds source
• 300 Hz of background in the downlink
• Few Hz of signal
• Too much CPU time to run backgrounds for full
  month
• Weve said we would run one day and re-use them
  for the rest of the month
• Now to figure out how to do that!
• Analyses involving less than one day duration
  will only see 1 copy of the backgrounds
• Otherwise we will see events turn up multiple
  times

3
Some Numerology

• Toby currently estimates 23 kHz input rate for
  backgrounds
• 86.4k secs/day
• From last weeks runs 13k triggered events take
  1800 CPU secs 0.13 s/evt (this includes sim of
  the events which do not trigger)
• 1 day input background 86.4k x 23k 2B events
• 2B 0.13 / 86.4k 3k CPU-days 300 CPUs for 10
  days
• After Onboard Filter - 300 Hz 26M events/day
• 1 TB for full trees for the day
• AllGamma (0.018-180 GeV) runs show 2.8k events
  taking 3.4k secs 1.2 s/evt upper limit on
  signal?
• 5 Hz signal 430k events
• 30 days ?115 CPU-days

4
Initial Proposal

• Ignoring details for the moment
• Create (logical) output tuple file interspersing
  background events from the one day
• Ignore deadtime effects (what can we do
  otherwise? We tossed the input event times!)
• Assume all background events are equivalent
• Only orbit dependence is rate
• Parametrize rate dependence in orbit
• Use 30 day pointing file to set rate and grab
  events from parametrization select at random
  from day 1.
• Intermix with signal events

5
Reality Checks Questions

• Final ntuple would be O(1B) events!
• Do we provide everyone with all events?
• And/or provide standard cuts to greatly pare down
  size
• Standard background rejection cuts?
• Loose cuts (10 solution)?
• Natural to correspond to discrete set of IRFs
• How to
• Reorder renumber events so they appear to be in
  order (else is great clue to analysts!)
• Point back to original tree events (hmm. Would
  have to hide this via the dataserver?)
• Parametrize the rate
• Just run background source? What are key
  variables? More than latitude and longitude? Does
  rocking angle matter?
• How to pick numbers of events vs time since rate
  is time variable (my ignorance obviously this is
  known since we do it in flux already!)?

6
More Wrinkles

• What if we didnt make an explicit final dataset?
• Hide everything behind the dataserver?
• It has one copy of signal and backgrounds and
  does bookkeeping to return a dataset for any
  query
• By default would always return same events for a
  given query (ie deterministic selection vs time)
• Could imagine allowing it to optionally randomize
  backgrounds as way to do multiple experiments?
  Does this make sense or is the right thing for
  people to just run ObsSim?
• Of course, people could ask for the entire
  dataset if they wanted 1B events ? 5 TB (hmmm)
• Ask for reduced set of columns of tuple?
• akin to L1 definition
• 25 vars (floats) would lead to 100 GB file