S Digel, D Band , R Sambruna, P Nolan, J Chiang, A Cillis, T Burnett, D Davis, C Shrader, M Ziegler, C Patterson, M Hirayama, J Carson, S Funk, M Razzano, W Focke, L Wai (8:30)
CS - Real time, hands on test of science tools by GLAST Users Committee, Nov 16-18, 1.5 days of use of science tools - distribution to be available today for internal testing and to be made available in about 2 weeks. Will distribute the documentation at at that time - want feedback to include how useful the documentation is. Emphasis is different from the DC2 exercise (taking a bunch of data and discovering things) - more like how usable we are for the user community. Many of the GUC members are coming in cold regarding the science tools.
Some tutorial presentations, most time to hands on and one-on-one. Experience with other missions shows that works a lot better than viewgraph presentations.
DB - They will have the software, documentation, and data for about 2 weeks before hand. Some eager beavers may come prepared but realistically not many.
TB - DC2 data?
CS - Yes. Will set up beta test Web site and share feedback.
No news
JC - Fixed calculation in pyLikelihood - v7r5 - a bug reported by Jean
AC - Working on Python script to produce TS contours in parameter space [described in last week's software meeting].
DD - Too early for GUC to look at that tool
SD - Handle the spatial part? DD - Not our plans right now
AC - May have something posted for next week
No news
MH - Development started on A4 tool - blind pulsar search - and updated documentation for the beta test
SD - Discrete FFT, right? Memory and CPU requirements required?
MH - Looking at that now - 1yr worth of data, say SD - Would have thought that ratio <time interval of weeks>/<shortest period searched> would be very large MH - Thinking about data in 1-day chunks, adding FFTs - reduces sensitivity but makes manageable
PN - In graduate school days with 64kbyte minicomputer - a lot of tricks for doing long FFTs that won't fit in memory - slow but does not cost sensitivity or resolution
MH - I'll talk with you after we have a test implementation
MR - PulsarSpectrum development plans - made MJDREF correction - and am working on timing noise - reading references and talking with Alice H about it - will add option to select 2 types of timing noise. Working on phase-energy distributions for Vela, other EGRET pulsars. Binary pulsars after that. Completing the tests on the phase-energy distributions
SD - Phase-energy distributions available now?
MR - Yes, mainly implemented for the EGRET pulsars. Not available yet. Plan is to link to Confluence page where the models are stored, will include the external model
MR - Timing noise is important consideration for being realistic about sensitivity to finding new pulsars - random fluctuation of phase - drift and shifts that are not strictly described by p and p dot and p double dot - high-order derivatives vary in a random way. For our purposes, the timing noise is an important factor for blind searches
CP - Time frame for having information available in Workbook?
MR - 10 days more or less, I think
SD - GUIs via st_graph?
DD - James, CS, and I have been talking about that - on the horizon - no concrete plans yet - but will do it
CP - Masa mentioned the pulsar tool updates and also Vincent Lonjou has updated the source identification (gtsrcid) tutorials, incorporating the DC2 tutorials. He'll integrate the 2 in the next few weeks. Biggest lack in the workbook is that we don't have any scripts that people are running - something that would be posted in Confluence and linked to the workbook
DB - We anticipate that while we start playing with the latest build we will begin updating and cleaning up the existing analysis thread tutorials - and will work with Chuck, get updates to him. Many people have said they feel that there's a gap between the threads, which tend to be very specific, and what would be a general introduction thread. I got started on one yesterday; there will be something like that, probably at least at first on one of our Web sites.
CP - When do you anticipate that being available?
DB - Yesterday
SD - What is general that is not covered by another thread?
DB - Well, tends to be repetitive with others - but like a quick immersion for something
SD - Cicerone?
DB - Have updated with comments from Analia - and working on others. Steve Ritz suggested that 3 members of GUC be 'alpha testers' and to look at the documentation as possible. Not clear how quickly they'll get to it, but in 2 weeks the documentation will be made availble to the GUC overall
https://confluence.slac.stanford.edu/display/ISOC/IRF+Working+Group+Meetings JC - Charge of the group is to get the 'handoff review' IRFs together for a year-long simulation and to make IRF generation more straightforward. Development schedule is compressed for the former - will meet again this week. Event class definitions, including 'standard' set of cuts will be examined. Need to work on implementation of integrals, test parameterizations and fits
SD - Handoff review is probably ultimate pre-launch set of response functions
DB - In the plots I see a dip around 1 GeV in front and back. Thought to be real?
TB - That is a feature inserted by the onboard filter, which does not take into account the low background rate at high energies. May be overriden but stuck with it for now.
DB - The responses will be useful for gtobssim and gtrspgen but not gtlikelihood?
JC - Only meant that the implementation is not complete - other member functions not implemented yet that are needed only for gtlikelihood
JP - This already checked in and available but would not be appropriate for use with DC2 data, right?
JC - Response functions are not availble through irfLoader package yet. Don't have a delivery date for that yet - could come after simulations are started
TB - As Jim indicated, it simply does not work now.
SD - James, gtrspgen fix news?
JP - Checked in a net improvement but still does not solve the issue - using the DC2 response functions, say, Front/Back A/B, so get 4 separate IRF functions that need to be combined to get the total response. The way that we were combining them led us to wonder about the normalization of the dispersion of that. Tried making overall average of dispersions and found that at high energies the normalizations of the individual dispersions does not come out near 1. And found a range of energies and angles for which the integral comes out near 0. Did not have time to track this down yet but a fix was needed - bizarre bump in high-energy response - so we hardwired the high-energy response normalization to be 1 per response function.
SD - JIRA issues - 41 now - please clean up - will make agenda item by development area next time
SD - Will meet in 2 weeks. Actually must confirm - need to get out of synch with catalog meeting again.