Additional Source Info

NRAO Interactive Services Modification Request 1 T3 2009



1. Introduction

The source information is not complete. For the velocity/redshift field there needs to be a reference frame and definition. After a meeting among EVLA and GBT stakeholders, it was decided that EVLA would make a suggestion for new format and parsing, so that import/export facility will also be defined. The requirements below are due mostly to David Harland, as we are trying to make PST and OPT import and export source catalogs compatible.

2. Background

3. Requirements

There are three ways to import source information into the PST: Manual, NED/SIMBAD, and Text File. Below we address the new parameters for each method.

Manual Input

  • Coordinate System: When adding coordinates include a menu list (including defaults) shown below under Telescope Specific Information. Label these as "Right Ascension" and "Declination" for equitorial; "Galactic Longitude" and "Galactic Latitude" for galactic; and "Ecliptic Latitude" and "Ecliptic Longitude" for ecliptic.
  • Velocity/Redshift: Change the GUI such that this is no longer a menu that selects either velocity or redshift but allows the user to input a number. The title should be labeled as "Velocity" if the convention parameter is either optical, radio, or relativistic. If the convention parameter is redshift then the title should be labeled as "Redshift".
  • Convention: Add a new column labeled "Convention" with a menu list (including defaults) shown below under Telescope Specific Information.
  • Reference Frame: Add a new column labeled "Ref. Frame" with a menu list (including defaults) shown below under Telescope Specific Information.

NED/SIMBAD Input

If possible parse the additional information about Convention and Reference Frame, if available. If this information is not available force the user to enter this information using the defaults shown below under Telescope Specific Information.

Text File Input

The new format for text file input is here. Below should be the same format data but with some complimentary information.

  • Current Format:
    • sourcename, ra, dec, epoch, velocity, redshift, groupnames
      • groupnames is optional, and there can be multiple names
      • either velocity or redshift, but not both, must be entered
  • New Format: we give up backward compatibility with the old format, but have a strategy for making it clear which format a given file obeys. The strategy is to change the delimiter to a semi-colon (';').
    • Fields and their order:
      • sourceName; groupNames; coordSystem; equinox; longitude; latitude; refFrame; convention; velocity;
    • Rules for Parsing:
      • A line without the requisite number (here, 9) of semi-colons is invalid.
      • Leading and trailing whitespace is permitted but will be trimmed. So, a source name given as " Sig A* ;" will be saved as "Sig A*".
      • The groupNames field is allowed to be empty, meaning the source is not part of any group. Note, though, that its position must still be accounted for. Examples:
        • Lone Source1; ; equatorial; J2000; 12:34:56.789; 87.654; galactic; radio; 1234.56;
        • Lone Source2;;equatorial;J2000;12:34:56.789;87.654;galactic;radio;1234.56;
      • Multiple group names are allowed. Names must be separated by a comma. Examples:
        • M31; galaxies, pretty things, fuzzy blobs; equatorial; ...
        • Dumbbell; nebulae; equatorial; ...
      • Whitespace before and after commas is permitted but will be trimmed. Thus the group names in the first example above are "galaxies", "pretty things", and "fuzzy blobs".
      • There should be predefined valid values for coordSystem, epoch, refFrame, and convention. We suggest using the GBT set found on page https://safe.nrao.edu/wiki/bin/view/Software/IntxSvcsMR5C409. Even if the EVLA/VLBA refer to LSRK as LSR, LSRK should be the valid value, not LSR. We should not have different telescopes refer to the same concept by different names.
      • We should state whether the predefined values above are or are not case sensitive. The parsers don't care which rule is chosen.
      • To remove ambiguity, we suggest not allowing empty values in the predefined fields mentioned above. Yes, we could allow defaults when those fields are missing, but the different telescopes have different defaults. In addition to the PST, the Source Catalog Tool (SCT) also parses these files. The SCT is telescope agnostic -- and must stay this way -- so we would not know which defaults to pick. In general it's always better in such files to be explicit and not to rely on assumptions about default values.
      • Longitude and latitude fields should be parsable as "ww:xx:yy.zzz" and as decimal degrees. The colon-delimited form will imply HMS for longitude and DMS for latitude.
      • Velocity is a unitless number. If the convention is "redshift" it is interpreted as a Z value, otherwise it is intepreted as km/s.
      • The precision in the position should be stored as entered, and displayed as stored.
      • Disallow special characters in source/group names.
      • Plan for, but don't allow for now, multiple velocities per source.
      • Add a feature to convert file with old format to new format. This can be when a user uploads a file with old format or an explicit button which will convert the file to a new format.

Telescope Specific Information

Since each telescope control system is different not all of the potential options are available. Below is a list of each option that should be made available for each telescope.

  • coordSystem
    • EVLA: Galactic, Ecliptic, Equitorial (default: Equitorial)
    • VLBA: Galactic, Ecliptic, Equitorial (default: Equitorial)
    • GBT: Equitorial (default: Equitorial)

  • equinox
    • EVLA:J2000, B1950 (default: J2000)
    • VLBA:J2000, B1950 (default: J2000)
    • GBT: J2000, B1950 (default: J2000)

  • refFrame
    • EVLA: Barycentric, LSRK, Topocentric (default: LSRK)
    • VLBA: Barycentric, LSRK, Topocentric (default: LSRK)
    • GBT: Heliocentric, Barycentric, LSRK, LSRD, Topocentric, Galactic, CMB (default: LSRK)

  • convention
    • EVLA: Optical, Radio, Relativistic, Redshift (default: Radio)
    • VLBA: Optical, Radio, Relativistic, Redshift (default: Radio)
    • GBT: Optical, Radio, Relativistic, Redshift (default: Radio)

4. Design

Technical lead should provide a brief description of how this will be implemented in the code.

5. Deployment Checklist

Documentation? Systems/hardware/networking things needed for deployment?

6. Test Plan

  • We need to text that the XML for GBT does not change vis-a-vis Carl's software.


Signatures

APPROVED: I acknowledge that my request is fully contained in this MR, and if the Open Sky (or other NIS or PST developers) deliver exactly what I specified, I will be happy.

ACCEPTED: I acknowledge that I have validated the completed code according to the acceptance tests, and I am happy with the results.

Written - - - - -
Checked - - - - -
Approved by Scientific Sponsor - - - - -
Accepted/Delivered by Sponsor - - - - -

Symbols:
  • Use %X% if MR is not complete (will display ALERT!)
  • Use %Y% if MR iscomplete (will display DONE)


Discussion Area

-- DanaBalser - 2009-10-12

Topic attachments
I Attachment ActionSorted descending Size Date Who Comment
srcTextFormat01.htmlhtml srcTextFormat01.html manage 10 K 2009-11-18 - 12:15 DanaBalser Proposed New Format for text file of Source information
This topic: Software > ProposalSubmissionTool > IntxSvcsPlanOfRecordT32009 > IntxSvcsMR1T309
Topic revision: 2009-12-17, OpenSky
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