This page describes how to use the new HST Duplication Checking tools.
You can use the HST Duplication Checking tools to find duplications of observations from your proposals.
To get started, go to the HST Duplication Checking page
and enter your proposal ID or your last name. Your observations will be checked against
planned or completed observations for cycles 7 through 16. Candidates for duplications will be reported back to you.
Caveats
Please note that these tools return possible duplications. Simply because an observation
from another proposal is reported as a duplication candidate does not mean that it is a duplication.
An observation is reported as a possible duplication if:
it comes from a proposal other than the one you're checking;
it is within 5 arcminiutes of one of your observations;
it uses the same instrument as your observation;
it has been or will be executed in proposal cycle 7 through 16.
If you find a conflict...
If you feel that a program is obtaining data that conflicts with
your proposed science goals, you may file a Request for Resolution of Data
Duplication (RDD) on the web at
You can also give a comma-separated list of proposal IDs, PI last names, or both; for example, 6972, 6974.
An exclamation point in front of a qualification will exclude it.
For example, if Professor Fuzzbucket wishes to check for duplications on all of his proposals
except for 6972 and 6974, he can enter fuzzbucket,!6972,!6974. All of Prof. Fuzzbucket's
proposals, excluding 6972 and 6974, will then checked for duplication candidates.
In the list of duplication candidates returned, clicking on the PEP ID will bring up the
abstract and all the observations, planned or executed, for that proposal.
You can also do more detailed queries through the Duplication Checking form.
The rest of this page describes how to use this form.
To use this form to do more detailed duplication checking queries,
enter enough information to find the data you want to check. For example,
you can enter fuzzbucket (case doesn't matter)
in the PI Last Name textfield to find all the observations for Professor Fuzzbucket's proposals.
You can also search on proposal ID, and use the other parts of the form to narrow down the search.
The output of a search like this returns the observations you want to check.
There will be a column labelled Duplications?, with a value of Check,
which will have a link on it. Click on the word Check in that column to
check that record for duplications.
The name resolver you want to use, if you want to get an object's coordinates.
To resolve an object's name into its coordinates, enter the object name in the Object Name field,
select either
NED
or
SIMBAD
for the resolver, and hit the Resolve button. The form will
be redrawn with the object's right ascension and declination entered as defaults in the RA
and Dec fields. Resolving an object name will not change any other choices
made in the form.
(You don't have to hit the resolve button to resolve a target
name. If you enter an object name and select either SIMBAD or NED, and
then hit the "Search" button, the script will get the coordinates before
doing the search. A message will appear at the top of the results page
showing you what coordinates were found for the object, or an error
message if the name resolver didn't work for some reason.)
We recommend that you use object-name resolution to find observations of fixed targets in the database.
This is the most reliable way to look up observations, because the observer could have given the observation
any name at all (for example, NGC1976 instead of M42, or PARALLEL-FIELD).
However, if you do know the name of the object, you can select HST Target Name,
in which case, the object name will not be resolved into coordinates, but will be used as a search qualification in the database.
(Remember when you do this to not press the Resolve button.)
The SIMBAD and NED object name resolvers can only resolve the names of fixed astronomical object;
they cannot compute the positions of moving objects (planets, comets, etc.).
The J2000 Right Ascension and Declination around which you want to search.
A number of formats are accepted for the RA and Dec. Here are some examples:
Decimal Degrees
185.63325 29.8959861111111
Hours, minutes and Seconds
12 22 31.98 29 53 45.55
12h22m31.98s 29d53m45.55s
12:22:31.98 +29:53:45.55
12h22'31.98" 29d53'45.55"
12h 22m 31.98s 29d 53m 45.55s
12h 22' 31.98" 29d 53' 45.55"
12h 22' 31.98" -29d 53' 45.55"
12h22'31".98 -29d53'45".55
12h22m31s.98 -29o53m45s.55
12h 22' 31".98 -29d 53' 45".55
Hours/Degrees and Minutes (no seconds)
12 22 29 53
12h22m +29d53m
12h22m 29d53m
12:22m 29:53m
12h22' 29d53'
12h 22m 29d 53m
12h 22' 29d 53'
12h 22' -29d 53'
The RA may be given in decimal degrees by indicating
a D or d after the degrees:
12d 22m 29d 53m
Spacing is not important, as long as the value is unambiguous, and that
you can delimit the hours/degrees, minutes, and (optional) seconds with
letters, colons, spaces, or any character that's not a digit or a
decimal point.
Note also that seconds of the form 31".98 or 31s.98 are accepted. This
should make it easy to cut and paste values into these fields from
electronic publications.
How far around the search position you would like to search, in arcminutes.
In the the results, we compute the angular
separation between each result dataset and the search center.
a radius. The results will be sorted on the angular separation by default.
You can use this radius to do fancy stuff like searching for all observations
between 2 and 8 arcminutes from the center of a galaxy (just give 2 .. 8
for the radius).
The date of the observation. More specifically, the date and time, in GMT, on which
the exposure was started. When specifying this date, you need to include a date and an optional time.
The date can have any of the following formats (the month name can be spelled out or abbreviated to three letters;
case is not significant):
If the day is omitted, the first day of the month is assumed. This means that a specification
like "July 1994" will look for observations done on July 1 1994 00:00:00,
not for observations done during July 1994. Note also that when entering a date with the month in
numerical format, the American ordeing is used; i.e., the first number is the month.
If a time is omitted, then midnight (00:00:00) is assumed.
Otherwise, you can specify a time in any of these formats:
14:30
14:30:20
14:30:20:999
14:30:20.9
4am
4 PM
04:30:20 AM
To search for observations before a given date, use <, and for observations
after a given date, use >. For example,
> Jul 15 1994
< Jul 15 1994
You can use the .. operator to search on a range of dates:
Jul 1 1994 .. Aug 1 1995
This operator is inclusive on the first date and exclusive on the second.
Finally, you can search on a list of dates or date ranges. For example,
Jul 1 1994 .. Jul 3 1994, Dec 1 1995 .. Dec 6 1995
will search for observations done within either one of these date ranges.
The HST proposal number under which the observation was executed.
This can be a numeric ID or a comma-separated list of numeric IDs.
For example, 5916; or to search for observations from either proposal
5410 or proposal 5916, specify 5410, 5916.
STIS GTO proposals for cycles 8 and 9 are included as well. They begin
with ST and have numbers from ST01 to ST52.
You can exclude a proposal by putting an exclamation point in front of it.
For example, !5916 would find all the observations
except those from 5916 that meet the other qualifications.
The proposal type; for example, GO, GTO/STIS, etc.
This field may be wildcarded, and an exclamation point may be used to exclude values.
For example, GTO*,!GTO/STIS will find proposal types starting with GTO
but not GTO/STIS. (Qualifications in this field are not automatically
embedded in wildcards.)
The aperture(s) used. You can give a comma-separated list, and use an exclamation
point to exclude qualifications. All qualifications are automatically embedded in wildcards.
For example, 512X512,!SLIT will find all apertures containing 512X512 except
those containing SLIT.
The filter(s) or grating(s) used. You can give a comma-separated list, and use an exclamation
point to exclude qualifications. All qualifications are automatically embedded in wildcards.
For example, F*N,!190,!200 will find all the narrow-band filters except
F190N and F200N.
A short description of the target, supplied by the observer.
like target names, these may not always be reliable- one observer's
CLUSTER OF GALAXIES may be another's ELLIPTICAL-
but they are generally better than nothing (especially where solar system
objects are concerned; planet, asteroid, and comet names are sometimes
more likely to be spelled out in the target description than in the target name).
As with the program ID, you may use a comma-separated
list, and an exclamation point to exclude some descriptions. For example,
to find galaxy clusters (but not stellar clusters), you might enter
CLUSTER, !STELLAR, !GLOBULAR. All qualifications entered in this field
are automatically embedded in wildcards.
Your choice of what columns you want to see in the output.
You can select your own output columns from this list.
The columns will appear in the search results in
the same order in which they appear in this list.
Choose how you want the output rows sorted. You can select
up to three fields to sort on. the rows will be sorted in the order of
the first sort field; if two rows have the same sort field, they will be
sorted in order of the second sort field, and so on.
For each field, you can select that the rows be sorted in reverse
order on that field by selecting the reverse checkbox. For example,
you can sort the rows with the most recent observations first by selecting
Observation Date for the first sort field and selecting the
reverse checkbox next to it.
Some queries will be capable of returning thousands of rows or more.
Such large search results tend to use up memory on both the client
and server sides, and aren't usually useful. By default, we limit
the number of rows displayed to 100 rows, but you can increase (or
decrease) this limit as needed.
Select this checkbox if you want to see the SQL query (or queries)
that the HST Search engine constructs from your query qualifications.
The query will be shown at the end of the search results.
SQL (Standard Query Language, pronounced either ess-que-ell or
sequel) is a language used by most relational database systems for
retrieving information from database tables.
The HST Search Page takes your search specifications and converts them
to an SQL query to run on our database. Viewing the generated query is
often useful for debugging, and may also be useful for SQL-literate
users who want to see what logic was used in the query.