Overall, the feedback was positive: the tools generally worked as advertised and the documentation was sufficient for people to get the tools to do useful work. Also, with Navid's work on installers for various platforms, what had been a big hurdle even for the science tools checkouts became essentially a non-issue, especially for Windows users.
David Smith and Tom Stephens gave summary talks - lessons learned from DC2 users. See the agenda page for the closeout workshop.
Much of the feedback was about additional functionality. Areas specifically mentioned (not exhaustive) included a point exposure tool, a source-finding tool, something like gtburstfit but with more functionality, and a blind pulsar search
In terms of analysis, a way to deal with the Moon (presumably as something like an extended source, or maybe directly as a moving source) was mentioned, as well as a tool or service for generating a reasonable model for the residual charged particle background.
Also in terms of analysis, ds9 seemed to be fairly widely used for displaying images and images with overlays. This is at least adequate, although we are fairly far from having a uniform style for presenting images, ala HESS. You can spot a HESS image from a long way off, except now MAGIC is also using the same style.
Also, the optimizers available within gtlikelihood did not return accurate error estimates, and some converged better and more efficiently than others.
GTIs proved to be kind of a stumbling point, especially when they were not transparent to users, e.g., when FITS files were merged.
Subsequent to DC2 we have realized that the XRB sources that were implemented in the sky model as PeriodicSources, came out a factor of several too faint. The reasons for this are not known yet. When the source specifications are run through gtobssim with the DC2 response functions and DC2 FT2 file, the numbers of gamma rays are much greater than in the DC2 data, and consistent with the exposure in DC2.
Also, as Jim Chiang realized last week, the DC2 energy redistribution functions introduce a bias in results from likelihood analysis. Actually, the energy redistribution functions (see slide 7 of Jim's presentation at the kickoff workshop) are not typically used directly in gtlikelihood but implicitly because the observed energy is used in place of the true (unknown) energy when looking up response functions. The energy calibration is set up so that the peak of the distribution function is at the true energy, but the redistribution functions are typically asymmetrical, and so on average the observed energy is a bit less than the true.