These are unedited, not guaranteed to be accurate, and in any case should not
be construed as including literal quotes of what people said.
SD, TS, JC, DD, CP, DB, PLN, TB, AC, JP
SD - DC2 summary from science tools perspective. Bias of likelihood results
traced by Jim to asymmetric energy redistribution
JC - Calibration energy dispersion - not true that calibration is set up at the
peak of the energy redistribution function - RR set things up so that the peak
is at the mean. What I played with and seems to work is to make an energy
correction on an event-by-event basis. Not clear yet whether to use average or
median energy, say.
DB - Will become default for likelihood?
JC - Yes. Note that gtlikelihood does have an option for convolution over
energy redistribution functions
DB - Point exposure tool?
SD - Was topic during first weeks of DC2 - discussed in Confluence
DB - In GSSC working on tool that produces time history of exposure. Sounds
similar - might be worth making it a standalone tool. Concept is Web interface,
something useful for constructing timelines. It would use an FT2 file as
input. Once we create timelines up to 3 weeks in advance, the planning tool
would create an FT2 file and the exposure/time history tool could be used to
project ahead.
Databases and related utilities
TS - Tied up with system tests - getting code releases out. Have not got the
final data files into the server - with MC_SRC_ID - file 650 needs diffuse
responses.
Need diffuse responses in GRT5 - will need new column names.
Likelihood
JC - st_graph improvements for log-log plots. Now can read par files in Python
version of likelihood, binned and unbinned. Did this by wrapping part of the
hoops interface that is available through st_app, but the readline library is
not working properly. Also, Dave Davis and Rita requested that fluxes of model
components be written in addition to counts. This is now in an output file that
can also be plotted as spectra. Right now only for point source components -
for diffuse components would require integral over ROI, say, and may not be
interesting.
RS - Thanks
SD - Spectra?
JC - In Python interface these are available automatically. Counts from ROI are
written out - observed and predicted
JP - st_graph formerly did not support log-log plots - now does. AC and I
worked together to get the plots looking nicer. If you set the plot option
parameter to yes, you get the model components and data and residuals. What we
were going to do next was to look at the issue of chi-square - goodness of fit.
Dave Thompson had a suggestion that is interesting - chi-squ value is misleading
- maybe better if for each data point you figure out the ...
AC - You figure out the Poisson probability comparing the predicted and observed
counts in each bin. Give warning if the probability is less than a number.
JP - Threshold would be a hidden parameter and would be level at which a warning
is generated. AC has written some test code. This would be our next project
for likelihood.
SD - Bins are for ranges of energy and bins of energy
JC - So if probability in any bin is outside of range, a warning is generated?
JP - Yes
PN - As the number of counts goes up the Poisson probability of any value gets
smaller and smaller
AC - We compared the total number of counts in the data with the number
predicted by the model in each energy bin
JP - Probability of getting that number of counts gets vanishingly small.
TB - There's standard way of dealing with this - compare the values with a
distribution according to the given model -
PN - Sounds like an attempt to use likelihood as a goodness of fit test - proven
impossible but people are continually trying to do it
TB - My experience is that you can do something like this - comparison with MC
generated models - then the normalization comes out ok - distribution of
possible values of the likelihood - and if the actual data value is much smaller
than any of these then can start to assume that the model is not a good
representation.
JP - We are hoping to find a 'badness of fit' measure - a warning that your
model is not reasonable
GRB tools
DB - No news
JP - Nothing particular
Pulsar tools
JP - Going along on the plan that was agreed upon earlier - coming up with a set
of classes that represents different time systems and different representations
- have finished the work on the library to handle all of that and have
integrated it into the tools - not tagged yet although mostly checked in - in
the short term there's no behavioral change in the tools, but in the future will
be able to alter the interfaces to generalize the allowed inputs, like allowing
multiple time systems. We are on track to have this done by the end of the
build.
Obs Sim
JC - Richard wanted to get gtobssim to report numbers of events generated vs
numbers 'accepted' - this is now in the mc_src_id output file - motivated by
understanding why PeriodicSource is different for gtobssim and Gleam.
SD - News about science tools version of orbit and attitude simulator from GSSC?
TS - We were discussing that today in our software meeting about what we need to
do - Dave Davis is going to take a look at it and see what we need.
Functionally it is there - so time scale is a few weeks.
TB - Will be interesting to run it for the DC2 kind of orbit to see how it
differs from the Stoneking one
TS - Should be entirely possible - not hard
TB - Does that include a pointing strategy I hope?
TS - Yes, you can give it pointed, rocking mode
TS - We could probably run that simulation any time - just a matter of setting
it up - need the starting vector - needs an ephemeris giving the position -
needs a TLE to go forward - easier if we don't know about the exact position.
TB - What we really want to know is are there the large overshoots to expose the
limb.
TS - Short answer is yes but not as bad - I checked - some excursions and that
may be partially due to the sun avoidence manuvers - but we don't know how the
SC does sun avoidance because that is ITAR and Giuseppe is not allowed to know.
TB - Issue is that we are currently using the Stoneking orbit by default for
background studies but should of course be using what we think is most
realistic.
TS - I can run off a 55 day orbit and get the FT2 file and send it out.
JP - ape replacement for PIL - 'ape' because it mimics other parameter
interfaces - all-purpose parameter environment.
JP - Current state is that ftools are in freeze pending next release and has
been integrated into FTOOLS/STDAS - getting quite a workout now - did not want
to inflict it on GLAST now. A direct drop in for 80-90% of PIL. For most
applications it will not cause a disturbance at all. In sciencetools we do use
HOOPS as a top layer to PIL and in HOOPS I had trouble doing things that we
wanted to do but PIL did not support. So code in HOOPS will simplify greatly
and not be as bizarre - conversion should not take all that long and then should
be a transparent replacement.
JC - After ape is available how long will modifying HOOPS take?
JP - On the order of two weeks
User Workbook Science Tools
CP - Workbook is current with all contributions received including binary
orbital phase calculation and observation sim tutorial and gtbackfile doc is now
available - under general tools tab. DC2 closeout issues/topics - please let me
know
Cicerone - DB - first draft was ready in mid-June - currently does not have
anything about pulsars or observation simulation - GSSC is talking about some
process of editing this - although nothing has happened yet. The point is that
this is very much geared for the user community that is coming in fresh not
knowing much about GLAST - this is to provide inside information that will be
useful for getting into the system - looking for comments and additional text.
Posted as a series of Web pages, and assembled it into a Word document - Word
doc is static - online version is evolving - so check update dates.