some lessons from the sdss j. gunn, ccat science workshop oct 2005

10
Some Lessons from the SDSS J. Gunn, CCAT science workshop Oct 2005

Upload: melinda-hoover

Post on 16-Dec-2015

213 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Some Lessons from the SDSS J. Gunn, CCAT science workshop Oct 2005

Some Lessons from the SDSS

J. Gunn, CCAT science workshopOct 2005

Page 2: Some Lessons from the SDSS J. Gunn, CCAT science workshop Oct 2005

Funding

The SDSS was `incrementally funded'. This makes foran interesting game for the institutional fundraisers, butis not particularly productive for the scientists. It isterribly important to have the funding in place early.

Page 3: Some Lessons from the SDSS J. Gunn, CCAT science workshop Oct 2005

Partners

1. In collaborations, as in life, pick them carefully. Collaborating

closely with people you do not like is possible, but unpleasant and difficult to make productive.

2. Institutional partners, whatever their merits, are likely to have

vastly different capabilities. This must be recognized by all concerned at the outset, and the organization and management must be flexible enough to cope with this smoothly.

3. In-kind contributions as part of the project budget are especially

difficult in a consortium and must be managed very carefully and

skilfully to avoid trouble.

Page 4: Some Lessons from the SDSS J. Gunn, CCAT science workshop Oct 2005

Organization at the University Level

The SDSS was run as a project under the ARC umbrella; this ingeneral worked well enough, but was not necessary; a consortiumbuilt especially for the project would probably have been better.

The governing body for the SDSS was an Advisory Committeewhich was a subbody of the ARC board of governors. Not a goodidea. Makeup of the AC was half scientists, half university financialadministrators. Maybe a good idea.

Consortium is a corporation. Very good idea, allows funding andspending flexibility.

Page 5: Some Lessons from the SDSS J. Gunn, CCAT science workshop Oct 2005

Management 1. Must have complete fiscal control (and as a prerequisite

complete trust of the consortium.) The fiscal authority of the management was never properly defined in SDSS, and the result was disastrous.

2. It is not a good idea for the project manager to be an employee

of a consortium institution.

3. The project manager must be able to control in-kind efforts.

Tricky, but necessary. In particular, in-kind must be measured

in real dollars, and, (we see in in hindsight), should be handled as a contract which can be cancelled as a result of poor performance, endebting the parent institution.

4. All of this is easier if the PM has an institutionally well-represented and carefully chosen advisory committee.

Page 6: Some Lessons from the SDSS J. Gunn, CCAT science workshop Oct 2005

Special Considerations for Running a Survey

1. The project is much broader than building a telescope and instruments, and demands attention to the broad software suite,

data model, data QA, data distribution, data access tools, etc.

2. In particular, these `data tools' need to be ready on the same

timescale as the telescope and instruments, and their commissioning needs to be integrated into the

commissioning of the hardware, so that at the end of commissioning,

the data are ready to flow.

3. Arrangements for public distribution of the data need to be worked out in messy detail with the consortium and with the

funding agencies, in particular the proprietary periods (which

in our view are necessary for data quality control if nothing else.)

Page 7: Some Lessons from the SDSS J. Gunn, CCAT science workshop Oct 2005

In a survey, the software task is much broader and more difficult thanfor a telescope project alone. If the PM is not an expert softwaremanager (and probably even if he or she is) a software manageris needed, reporting and responsible directly to the PM and his/heradvisory committee

Software Management

Page 8: Some Lessons from the SDSS J. Gunn, CCAT science workshop Oct 2005

A survey is very different from the scientific organization point of viewfrom building/commissioning a telescope and first light and subsequent instruments. Several questions need to be asked atthe outset:

1. Turf. Is there any? Who gets to do what science during (and after)

the proprietary period.

2. Should there be `Key Projects?' If so, how should they beorganized?

3. Should outside collaborators be allowed? encouraged? Howshould they fit into the goals of the collaboration?

4. How should the telescope/instrument scientists be integrated into

the survey science output?

Scientific Organization

Page 9: Some Lessons from the SDSS J. Gunn, CCAT science workshop Oct 2005

And some general issues:

5. Data releases and data QA are very time-and-effort-consuming, and must (we find) be largely executed by the scientific core of

the project. These tasks must be distributed equitably.

6. A mechanism must be in place (even if never used) to arbitrate

disputes over authorship, individual rights, protection of students,

etc....and these issues must be dealt with for general cases ab initio and clearly.

7. There is no substitute for communication, face-to-face whenever

possible, certainly often enough and for long enough for theprincipals to be comfortable with each other, and by phoneregularly.

Scientific Organization 2

Page 10: Some Lessons from the SDSS J. Gunn, CCAT science workshop Oct 2005

Take the time and the money to do it (whatever IT is) right the first time whenever possible. Shortcuts are never cost-effective, either in dollars or time in the long run....and usually the long run is pretty short. The quality of the data at the output of the survey is dependent on an enormous array of factors, and it takes very littleshoddy input to contaminate the whole affair.

And, Finally, a ManagementPlatitude: