These are unedited, not guaranteed to be accurate, and in any case should not
be construed as including literal quotes of what people said.
S Digel, A Cillis, T Burnett, P Nolan, J Chiang, C Patterson, D Band, J Carson,
W Focke, J Cohen-Tanugi, J Peachey (8:34)
Databases
No news (Tom was probably attending the Ops TIM today)
Likelihood
JC - 5 items - LW asked for different pixel sizes in longitude and latitude for
gtcntsmap; J-MC wanted custom energy ranges for gtcntsmap - now
does it via gtbindef; JB wanted the pipeline to run faster by avoiding
calculation of likelihood contribution for terms/sources that don't change -
information needs to be cached for each event but this does speed things up for
the calculation in the catalog pipeline by factors of several; also
gtlivetimecube is now faster (no longer pays attention to time intervals
that are not relevant to the requested livetime calc) and gtmodelmap now
writes a GTI extension, a copy of the GTI for the input counts file.
SD - Would anyone want to use custom bins for binned likelihood analysis or is
ability to specify bins something that would be useful for people like Diffuse
group who want to make EGRET-like maps?
JC - The custom binning is not useful for binned likelihood that I can see.
Note that eventually the functionality of gtcntsmap will be folded into
gtbin
AC - [I could not hear very well] Working on making contour maps of confidence
ranges of parameters in likelihood fits
GRB tools
DB - JP will try to arrive later; and TS is over at Ops TIM. Last time
there was a question about gtburstfit. The version that runs on binned
data works; this is a tool that does a pulse fit to data - has a nice GUI. Does
not work on unbinned data. Jeff Scargle has methodology for this but needs to be
integrated, according to Jay. gtbin actually already does the ra,dec
maps for different energy ranges. So in terms of what is exposed to the user
community gtcntsmap will be retired. gtrspgen is being tweaked so
that it treats the response functions in the same way that the other tools do so
interpolations, etc. are in common
SD - gtburstfit is the ultimate GRB tool, temporal and spectral model
fitting?
DB - More modest than that - fits pulses to temporal profiles, after it decides
what the pulses are - very much a temporal analysis in one energy band - one
light curve
JC - Have you used this on any simulated data, like DC2 data? Last time I tried
it, it only would work on binned Bayesian blocks, unbinned not implemented, and
for the fitting it seemed like you needed to have the pulses from the Bayesian
block method. Also what does it do about START/STOP times and what does it do
about background levels?
DB - You are asking more than I know. James demonstrated the tool for me
yesterday. What they are using is basically BATSE data - I don't know the
format - but does read FT1 files - it reads the unbinned data but effectively
makes a bin for every count - so the unbinned part is not working - Jeff S has a
way to make it work but it has not been communicated to James yet - Bayesian
blocks is really an inital guess - the fit that is done is comparing a pulse
model to the real binned data. I don't know what assumptions are made about the
background. It could be that as part of the BB it makes a background - a
constant level before and after the burst. The output is thus far only to the
screen, gives parameters for each of the pulses, including reduced chi-sq, can
tell by eye if a pulse exists but is not being picked up by the Bayesian blocks
Obs Sim
JC - Working with Toby we now have gtobssim working like Gleam in
terms of assigning the same MC_SRC_ID to a given source across runs
SD - Like for DC2 Gleam runs, increment by 1000 between source definitions?
JC - Depends on how each composite source are presented to the flux package -
each composite source is incremented by 1000.
JC - A couple items - David had posted a couple of items regarding FT1/FT2
formats regarding keywords. I implemented his recommendation about time keywords
appearing in the first extension header. The 2nd issue was about the time
system for the observation time - current implementation does not account for
leap seconds, would need to be resolved in the astro package.
DB - Convention is that DATE-OBS and DATE-END follow the TIMESYS keyword. And
that is TT
TB - Happy to do something but not sure what we want - need to take offline and
come up with a specific proposal - implementation should be straightforward
SD - Will take this up via e-mail
User interface
Plotting in tools
DB - At the moment the tools that have plotting are gtburstfit
(interactive plotting), gtlikelihood, and gtpsearch. It seems to
me that with this package we have a lot of other things that could be shown,
although people will probably take FITS to ds9, fv, etc. Probably would be
worth adding simple displays, like grayscale pixel map to gttsmap.
Model-making tool that could make map with dots for where sources are.
gtrspgen could display cuts through response matrices - pixel maps of
response matrices; gtpphase could make a crude light curve. For some or
many of these some modest amount of plotting could be useful.
SD - Could be grafted on to the science tools - hard to argue against - could be
supported at GSSC?
DB - Don't know about resources
JC - Comment is that the modelEditor tool does what David mentioned - if
you have a ds9 window open it will show you the positions of the sources
as they are added.
For James - for the gttsmap application it would be nice if it could
throw up an image frame when the program starts and then update pixel by pixel
- is this technically possible with st_graph? [James had lost VRVS connection at
this point; also we were running out of time in the meeting and did not discuss
further adding plotting to the tools]
User Workbook
CP - Masa sent updates to the 6 pulsar tutorials yesterday; I'll be updating
them but posting them to the Web should coincide with the next science tools
release - wondering when that is planned. Also wondering if there's a place in
Confluence that people are posting script files that are used for automatic
different analyses, would be a useful link for the workbook.
SD - Good question about when date for the next release
DB - Has been discussion here about the Beta test by the GUC - working back in
time - to give time to try to break the tools
JP - Build 20 ends on Oct 13. (At offsite meeting at 10 am on Wednesdays now.)
DB - Oct 13 sounds a bit late - would like to have more time to evaluate the
tools, I think.
SD - Another week?
DB - Once the tools are released then we would be applying the tools to the
data. Also the issue of making installation packages and checking that they
install properly.
JP - Friday vs. Monday are equivalent -
DB - Oct. 9 is Columbus day
JC - Should do major release on schedule and apply tags as things become
available. [That means the release will be Oct. 13 but HEAD versions of
the Science Tools with essentially that functionality will be available soon
from the Release Manager.]
Cicerone
DB - Got comments from Chris on the pulsar section and Analia sent comments
yesterday - will get posted tomorrow
IRFs
TB - (see linked presentation on agenda page) Describing the procedure that was
developed under Jim's leadership. We start with a set of MC generated files
called AllGamma - fill the phase space in energy and angle and allow to measure
the response given the statistics of the events and the validity of the monte
carlo. Based on analysis we decide as class definitions - like DC2 Front A -
and by the way this is highly relevant for science tools because gtlikelihood
and gtobssim (and gtrspgen) depend on having valid instrument
response specifications. Events are selected according to a set of cuts that
are inherent in the definition and then 3 paths - (slide 2) left JB in Paris -
center me in Seattle - right RR in Padua for the Aeff, PSF, and energy
dispersion - to make a set of tables
slide 3 - Jim integrates these tables - marvelous code - takes the name of the
response function, give is to IRF factory, which uses information in CALDB to
provide IRFs (it knows the functional representations of the parameterizations)
My proposal - which is only that - is to consolidate this and limit the number
of steps that involve people.
slide 4 - New package to demonstrate feasibility - fitting itself is fast and
reproduces DC2 results; for now using ROOT instead of CALDB
slide 5 - CALDB would be easy to add
SD - Implement the integrals (?)
TB - Likelihood and gtobssim require partial integrals of the PSF and dispersion
and that is part of the interface that Jim has defined and that Jim has
implemented; my current implementations just return 0.
JC - Some refactoring needs to be done - some base class could do the bulk of
the work - some tradeoff between generality and efficiency - in terms of
speed/accuracy
[We ran out of time before the next meeting of the morning. Next science tools meeting likely will be in 2 weeks. We did not get to the topic of open JIRA issues; I asked people who were reporters or assignees in the posted list to let me know if the issues were in fact still open.]