NAASC comments on OT Phase I process (Feb 2009)

Legend

  • Green = Dana Balser
  • Blue = Todd Hunter
  • Red = Jeff Mangum
  • Purple = Group (above plus Crystal, Al, Aaron)
  • Tan = John Hibbard

Accessing the Observing Tool (OT)

  • Q1: Our starting assumption is that a PI must be a registered ALMA user, via the ALMA "portal" before beginning to create a proposal. Possibly even before being allowed to download the ALMA Observing Tool software.

JM: This sounds like a reasonable infrastructure. I think that you need to be able to keep in contact with your users, and a user "portal" is a good way to do this.

DB: The current NRAO Proposal Submission Tool (PST) is a web-based tool that requires the user to be registered. It also requires that the PI and contact author on any proposal to be registered. We have had a lot of problems with duplicate names and profiles that are out of date. Part of the problem was self-inflicted when early versions of the PST provided ways for people to create these duplicate accounts. It would be useful to spend some effort on this now rather than later. Since once the duplicates are created it can be time consuming to resolve them.

o Note: We will provide for the ability to install a "site-wide" version of the ALMA Observing tool. This means there will be a way around the requirement to register before downloading. In addition a moderately software-literate user will be able to share the OT with others in any case. It is technically possible to stop this sharing, but we do not believe it is worth it.

JM: I don't see any danger in this. For example, you could have "users" who simply download the OT, give it a try, then decide that ALMA is not for them. Perhaps you want to force registration to an ALMA "portal" at the proposal submission stage?

Phase I investigator and Project details

Note that we intend to make use of the ALMA User database as the source for detailed information about registered ALMA users. Thus the OT user can search this database to find themselves or their co-investigators. However, we also intend that CoIs can be added without registration.

Presently in the OT we have items for:

Project Name
Project Version
The Principal Investigator (PI)
The Co-Investigators (CoIs)
Project Title
Abstract
Proposal Type. Currently the list is: COORDINATED, LARGE, LONGTERM, NORMAL, RAPIDRESPONSE
Scientific Category. Currently the list is: EXTRAGALACTIC, GALACTIC, STELLAR, SOLARSYSTEM
Contact Person (from the investigator list).
Support required (currently free form text)
Related proposals (currently free form text)
Previous proposals (currently free form text)

  • Q2: What details of the PI should the OT present? Bear in mind that the main item will be a link to the record in the user database, where the information will really be stored.

JM: I think that the OT needs only present very few details about the PI, as these are stored in the user database.

DB: What information defines a user? A person's name will not necessarily be unique. The PST specifies a username which is created when a user registers. It might be useful to present enough details in the OT such that collaborators will be able to distinguish people with similar names. Maybe name, affiliation, and email address.

JH: name, institution & email at least. For science category, I would use the following: Cosmology, high-z, Galaxies, Galactic Nuclei, ISM, astrochemistry, star formation, protoplanetary disks, stars, stellar evolution, planetary systems, solar system, sun. This will not be the panels, but would enable us to mix and match topics to get useful panel sizes.

  • Q3: What details of the CoI should the OT present (if the CoI is already registered) or capture and store (if the CoI is not yet registered)?

JM: Same here as above.

DB: Maybe the same as the PI for similar reasons.

  • Q4: The Ops plan suggests/implies that the PI is the contact person. Is this to be enforced and so we drop this item?

JM: I think you should allow for a separate contact person.

DB: I think it should be possible that the PI and contact author are different people.

NAASC: depends on how time is assigned. If 100% based on PI, then no other contact people, to avoid people "fronting" proposals. Otherwise, should allow a technical contact. But if you don't shouldn't matter - PI should pass all relevant info on.

  • Q5: Is there a need for a separate project name? (Currently we have items for both Title and Name).

JM: I can see useful flexibility in a separate "short" name for the project, separate from the title.

DB: I am confused about this in the OT. By "Name" do you mean the project name and by "Title" the proposal title? If so, what is the difference between a "Project" and a "Proposal"? Can you have more than one proposals per project?

  • Q6: Is the Project Version useful? This is an item intended for the user, to aid them in tracking versions. But they may not use it. It does seem to be used (and useful?) by the CIPT test and the AIV teams.

JM: I would imagine that the database will naturally store this version information, so why not keep it?

DB: This seems useful to me. It appears that collaborators that wish to work on a proposal will have to pass the aot file back and forth, correct?

  • Q7: Is there a character limit for the title?

JM: Obviously driven by the tools that access this information in the database.

DB: The PST has a limit of 80 characters.

  • Q8: What is the size limit of the abstract? (Characters? Words?)

JM: Same here as above.

DB: The PST has a limit of 200 words.

  • Q9: General question: Are the items and options above what is required? In particular the options for Proposal Type and Scientific Category.. Note: If possible I want to remain compatible with the NRAO Proposal Submission Tool

JM: Must be vetted by Ops.

DB: Here is what we have in the documentation for the PST:

  • Proposal Type
    1. Regular Proposal: A proposal which requires small allocations of telescope time, less than 200 hours. Proposal deadlines are once per trimester.
    2. Large Proposal: A project which requires large allocations of telescope time, at least 200 hours.
    3. Rapid Response Science: Exploratory Time or Target of Opportunity proposals.

Note that proposals for observations of Known Transient Phenomena are considered Regular or Large Proposals, as appropriate. There is a separate category called "Joint" that specifies if the observations require more than one NRAO telescopes (e.g., a joint proposal that requires the VLA and GBT).

  • Scientific Category
    1. Solar System: Sun, planets, satellites and comets. (Not included for VLBA/HSA proposals.)
    2. Stellar: Neutron stars, stellar-mass black holes, pulsars, X-ray binaries, planetary nebulae, circumstellar shells, supernova remnants, masers, novae, supernovae, and stars.
    3. Galactic: Galactic structure, galactic center, molecular clouds, HII regions, star formation, and the interstellar medium.
    4. Extragalactic: Normal and active galaxies, radio galaxies, clusters, quasars, extragalactic molecules, and cosmology.
    5. Astrometry/Geodesy: Only for VLBA/HSA.

The PST also includes an Observing Type. I am not sure if this would be useful for ALMA or not but the details would, of course, change. It might be useful in ALMA decides to have staff contacts associated with each proposal.

  • Observing Type
    1. Continuum
    2. On-the-Fly Mapping
    3. Single Pointing(s)
    4. Grid Mapping/Mosaicing
    5. Planetary Radar
    6. Solar
    7. High Time Resolution
    8. Polarimetry
    9. Spectroscopy
    10. Monitoring
    11. Pulsar
    12. Triggered Transient (Proposal types Regular or Large only)

Science Justification and related documents

A Science case must be attached to the proposal. Additionally we currently support the attachment of an arbitrary number of other supporting documents, e.g. images or whatever.

  • Q10: Details about the Science case are needed: Formats accepted? Length restrictions? Will there be a template? (3.0R4 just says "easily printable" and offers postscript, pdf as suggestions. Ops6.1.1 says nothing on format)

JM: Question for Ops.

DB: The PST has the following limits:

  • Regular or rapid-response proposals will be allowed a maximum of four (4) one-sided pages (US letter sized) with 11 point font (minimum) to present the scientific justification and the technical feasibility of the project, including all figures, tables and references.
  • Large proposals will be allowed a maximum of ten (10) one-sided pages (US letter sized) with 11 point font (minimum) to present the scientific justification and the technical feasibility of the project, including all figures, tables and references.

The PST only allows PDF or ASCII. I recall that there were problems with postscript (e.g., A4 vs. letter; concatenated postscript files; etc.). I don't think a template is necessary.

  • Q11: Regarding other supporting documents. We have essentially no information on what ALMA might want here. Possibilities are that ALMA Ops might want to require certain additional documents, e.g. an observing plan/technical description or technical case.

JM: Question for Ops.

Items Completed by the Observatory

The following items are available in the project/proposal, but are completed by the observatory, they are read-only for the user: Note: It is likely that a sufficiently privileged ALMA Staff member can write these items, possibly via the OT.

Cycle: A static value for each semester, inserted by the OT (will change with each OT release, for each cycle) 
Date received: The date the proposal is successfully submitted to ALMA.  
Project code: A unique tracking identifier given to the proposal/project following a successful submission (see Ops6.1.2)
Staff contact: The name of an ALMA staff contact for the project (or ARC person?) Inserted at some point following submission (TBD)

  • Q12: We need to provide a mechanism for a staff member to select this proposal as DDT or Observatory calibration or engineering or whatever. How should this be done?

JM: Yet another Ops question, I think.

  • Q13: Is the Staff Contact item necessary and useful?

DB: I think this is useful if there are enough resources. Otherwise the user will start calling whoever they can to find the information they need which is not particularly efficient.

JM: I think yes.

Group: Staff contacts should not be issued at Phase I. The helpdesk should handle queries at this sage. Accepted proposals (A & B ranked) should be assigned a staff contact, but note that we have only budgeted 16 minutes per proposal in the staffing plan!

  • Q14: Is there a need for the assigned agency partner (ARC) to be inserted and stored?

JM: I think yes.

Yes. Users need to be aware of the ARC concept as well as know which one will service their needs.

Group: this could be either entered by the user or computed using some approved weighting algorithm. It should not be automatically keyed from the PI's affiliation.

  • Q15: Is there a need for data processing and/or publication plans to be provided? (See ops6.1.1, which says "TBC" for this item)

This should probably be an optional section in the scientific justification, rather than a separate item in the Phase I list.

  • Q16: General question: Is the above what is wanted? What is missing?

Polarizations required: single linear, double linear, full-stokes. For Band 7, additional options using a quarter waveplate: single circular, double circular, full-stokes (circular)

  • Q17: What about some flag that says that the user wishes to be considered an "expert" user? What I mean is that the user wants to be able to write their own observing scripts? Then the observatory accepts or denies this request?

JM: This is a slippery one. How are "experts" vetted by Ops?

I don't like the idea of the observatory judging user capabilities at Phase I. Perhaps the internal contact could make that judgment during Phase II.

Target list and observing summary

The user then needs to enter details of the targets and observing that he/she wishes to do.

The design of the OT means that the information captured at Phase I may be all that is required, and fully complete ready for Phase II (also meets requirement 3.0R3). However, the information required at Phase I, to allow the Operations staff and the PRC to do their jobs, will be a subset of this. It is completion of this subset that validation will measure against during Phase I. In addition the OT will determine much information at Phase I (an example being estimated data rates) from the input. This allows us to infer some of the input we will need.

Presently we assume that the subset of information required at phase I is:

source name
source coordinates
  • plus equinox if non-J2000 is supported (and epoch if proper motion is significant)
  • For comets/asteroids, specify some source of special ephemerides
type of map
type of spectral setup - continuum or "full" (i.e. multiple windows)
lines and/or frequencies to observe
angular resolution
largest angular scale needed? - for aca use determination
sensitivity (rms)
  • Need separate entries for continuum and each spectral line
field of view required (i.e. size of map)?
presumably need spectral resolution/bandwidth?
  • Yes, it should be specified for each individual spectral line
and dynamic range?
  • Spectral and spatial
source flux? (3.0R5)
  • Some observatories require this, but I don't see how this is useful. It is too general of a question (line vs. continuum, single-dish vs. interferometer uvrange, etc.)
What calibration decisions are needed at this point? (Ops 6.1.1 refers to "special calibrations required", also 3.0R12 "specifying real-time checking")
  • required passband measurement accuracy (phase and amplitude)
  • required flux measurement accuracy
  • required polarization accuracy
  • required astrometric accuracy
  • required level of sideband rejection
  • special fast switching requirement -- e.g. requested maximum gain calibration switching period (i.e. not to exceed XX seconds)
  • special weather conditions (if the standard conditions for the sky frequency requested are insufficient, e.g. transiting exoplanets in Band 7)

Presumably also a parameter to request ACA observations, regardless of automatic recommendation.
  • Need a similar parameter to request total power antennas

From this information the OT will determine the following, and present as feedback to the user (and operations staff):

Antenna Configurations needed
Exposure (integration) times needed, total time needed (overheads included)
Whether or not ACA should be used
Receiver bands needed
Correlator modes needed? (And observing modes needed ??) (3.0R7)
Data rates/volumes expected. 3.0R9
Data quality expected (??) - see 3.0R8
Atmospheric quality requirements (ops 6.1.1)
Fraction of time expected to be available for these observations (3.0R6, ops 6.1.8) - Note: need tool from scheduling

  • Q18: Is the minimum information captured from the user sufficient and necessary? Please note question marks against some items. (Ops6.1.1 and 3.0R3 provide input, but leave uncertainty)

JM: I tend to prefer "more" than "less" information, so would like to see all of the items, plus those with "??", included.

  • Q19: Is the above information derived by the OT enough for Operations and the PRC? Again there are question marks against some specific items.

Some additional items:
    • Report the gain calibration switching period used in the overhead calculation.
    • Report the integration time and total time spent on passband, flux and polarization calibration. This calculation will need to be done at some representative elevation/hour angle since Tsys is such a steep function of elevation in the higher frequency bands.

Finishing up and submission

The OT will be able to provide a printable summary form of the entire proposal and the derived resources required (for both the PI and staff). It will also provide validation against the presence of and the value of required items. During submission authentication of the user will be required, and a validation will be enforced. Proposals failing this validation will be rejected, with a report returned. After the Phase I deadline all Projects become subject to ObOps.

  • Q20: Can we assume all submissions go to Chile? And what about retrieval for phase II? I.e. is there a single submission/retrieval point for the OT user?

JM: This would be the cleanest structure.

  • Q21: We assume that any registered user may submit the project, even if they are not the PI. Is this reasonable, or should we require it to be the PI?

JM: Hmmm. Not sure about this one. What does GBT/VLA do?

Yes, any registered co-I should be able to edit.

  • Q22: We assume that a submitted Proposal may be updated (overwritten) at any time up to Phase I deadline - is this true?

JM: This is a good model.

DB: Maybe you should have an option to withdraw a proposal. So a user would have to withdraw a proposal first before resubmitting it.

More general questions

  • Q23: What will be the policies regarding target of opportunity and directors discretionary time proposals? How are they signalled (project code?) Accept at any time? Ops6.1.10 is unclear on process.

JM: Question for Ops.

DB: I think you have to accept certain target of opportunity proposals at any time since they could be also be rapid response proposals.

  • Q24: For early science will there be a list of observing modes supported? Capabilities of the observatory offered at this time?
    • I sure hope so.

  • Q25: Are SB dependencies, and/or breakpoints to be highlighted at Phase I? Are these Early Science requirements, or later?

JM: Certainly at Phase II, but I am not sure about Phase I.

  • Q26: Where items need documentation who will provide this? (Obsprep can clearly document items, but some may have a specific meaning determined by Operations - for instance data reduction plans).

JM: Is Alan asking who will write the documentation? If so, this is a good question...

  • Q27: Q17 raised a simple question about "expert" users, but the more general question is has it been determined how this process will work yet? I.e. which users, if any, will be allowed to write their own observing scripts, and how should this be enforced?

JM: This was always a thorny issue when we discussed this subject in the SSR. I bet that this has not been fleshed out. Another (rather difficult) Ops questions, I fear...


-- ToddHunter - 17 Feb 2009
Topic revision: r1 - 2009-02-19, ToddHunter
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback