VLA Pointing Corrections
Description: In order to maintain the pointing accuracy of each VLA
antenna, pointing observations are made with the VLA. We are now in
charge of the analysis of the pointing data. This analysis leads to
an update of the pointing models for each antenna.
The VLA operators usually run pointing roughly twice a month.
They
run two types of pointing observations. One is refered to as an
X-band 'reference' run and the other is refered to as a
'subreflector/rotation' run observed at several bands.
The VLA operators will transfer the pointing data off of the
MODCOMPS
to banshee. Phillip Hicks will move the file to
/home/vlbiobs/pointing/ and notify us when it is there.
- The VLA operators will Email an observing log to us when
pointing was
observed. They will also send us some maintenance reports and weather
plots as well so that we can determine if the weather was poor or an
antenna was broken.
-
cd to /home/vlbiobs/pointing/.
The initial pointing data will be in a file with the format
<A><YYMMMDD>.PNT where A is equal
to N
for night, D for day, O for offset, and R for reconfiguration
(example: N99MAY10.PNT). Copy the file to /home/vlbiobs/pointing/.
In rare cases, lines with funny or missing
characters may have to be deleted so that peek doesn't crash.
Some lines refering to antenna #29 (i.e. Pie Town) may have to be
deleted as well.
-
Run peek
-
inp
-
workingset AYYMMMDD (or the name of the .PNT file)
-
elevation 12.0 120.0 (Use a minimum elevation of
twelve degrees.)
-
band X (or a list of whatever bands were used in the
observation)
-
windspeed change only if needed to get a solution for
a badly
needed antenna during poor pointing weather. Otherwise, leave it
alone. (If you have to set the windspeed, then you probably need to
scrap the whole observation.)
-
go (use defaults for the rest of the inputs)
-
q
peek is a FORTRAN program maintained by Chris
Carilli.
Direct questions to him about peek
peek spits out several files. It creates a
.const, .changes, .(freq)rot and .PTR files. We are
interested in
the .PRT and .CONST files, or the .(freq)rot files
if this is
a collimation observation.
- In the .PRT file (ex. N99MAY10.PRT) of an X-band reference
pointing run, there is a section for each antenna called: POINTING
EQUATION SOLUTIONS FOR ANTENNA #. This section lists the old, new,
change, and error to an antenna's pointing model coefficients ( 7
azimuth
and 5 elevation parameters). The change and error numbers for each
parameter must be check against one another, and if the magnitude of
the change value for a specific parameter is at least 3 times greater
than the error value, then all of the new coefficients will be used in
the final pointing file by the VLA operators. Otherwise,
the old pointing coefficients are used in the final pointing file.
PEEK makes these determination automatically and places
them
in the .const file which is used by the VLA operators.
Whether the old or new numbers are used needs to be determined for
each antenna. A quick check of the integrity of the data is to make
sure the Postfit rms Errors are not much greater than roughly 10
arcseconds.
-
For Collimation offset runs (also called rotation or subreflector
runs) the initial data file that is needed will begin with an "O".
These are multi-frequency files used to determine collimation errors
with respect to each specific feed on an antenna. After running
peek, the COLLIMATION OFFSETS section of each antenna
listing
in the output .PRT file needs to be examined. Check the
change and error solutions for each band. If the magnitude of the
change is greater than 3 times the error for either the elevation or
azimuth offset, use the new offsets for that frequency and antenna;
otherwise, use the old offsets listed. Ken Sowinski must check over
and approve the offsets for the antennas at Q-band.
-
Like the reference pointing run, a pointing file with collimation
offsets for all antennas needs to be created for each frequency. These
files needs to be used by the VLA operators.
- Email the Phillip Hicks and notify him that the pointing files
.const or .(freq)rot are on
/home/vlbiobs/pointing/
Preparing Coordinated Millimeter VLBI Array (CMVA) SCHED
files.
Description: CMVA runs are extremely non-standard. They involve the
VLBA antennas which have 3 mm receivers and other millimeter stations
which use the older Mark III formats. Vivek Dhawan handles most or
all of the subtle tweeking that these projects need.
The CMVA is run by Bob Phillips at Haystack Observatory. Almost
everything
is MKIII format and is usually correlated at Haystack. This is still
rather
nonstandard so see Vivek Dhawan or Joan Wrobel if you have questions.
- Find out when the next session is scheduled - from Barry Clark.
Or see
each months schedule.
-
Look around at old session files to orient yourself with what is needed.
-
Nag Bob Phillips two weeks before session to produce .drg file. Several
PI's projects are combined into one or more .drg files. lasting 2-5
days.
Phillips should also send a summary of frequency setups,
detailing which
BBC's, polarizations, and tracks he wants recorded at the
VLBA-controlled
sites. Vivek can usually figure this out, but it sure helps to have the
summary explicitly from the scheduler.
- Get .drg file; edit it to put in correct station names if
necessary; get
code for experiment from Peggy; e.g. c973 for CMVA '97 session 3.
-
Locate header files, e.g. mkiii.head in
vlbiobs/vlbiobs/jwrobel/mmmyy/astr/project/
and copy it to upcoming project directory.
-
THE IMPORTANT STEP. Make appropriate setup files as needed,
corresponding
to the $CODES section of the .drg file. Many examples now exist, see
the
files in /home/vlbiobs/astronomy/apr97; /jun97; /oct97; /dec97; also
see summary.set
(if one exists), and comments in the setup files. Vivek will see about
merging these setups with Craig Walker's standard ones when we settle
on
a standard set. These are all made-to order for each session/antenna.
Essentially,
the track assignments for the VLBA recorders are matched to the MKIII
ones
detailed in the $CODES section of the .drg file, with the caveats that
MKIII follows a USB, LSB sequence, and we do the reverse; and that the
first VLBA data track is #3. Thus (1, 15) from the $CODES translates to
tracks 18, 4; etc. "Mode A" is equivalent to tpmode=1; "mode B" to
tpmode=2.
-
Run skedconv for ALL stations. (Only the VLBA ones are needed, but this
makes the whole experiment clear - subarraying, etc.) Skedconv will ask
you for header and setup file names, and produce a keyin file to
control
the running of SCHED, to actually make the schedules.
-
Cut and paste cover info from an old session .key file (to keep SCHED
happy)
to the skedconv output.
-
Edit the stations table in SCHED.key file to put in correct station
CONTROL
type - e.g. VLBA, MKIII, MK4. Effelsberg has 2 separate data
acquisition
systems, down to the recorder, controlled by SNAP for MKiii, VLBA for
stcode
EB_VLBA (CMVA usually is SNAP.)
-
Finally, run SCHED, deposit on vlbiobs, and do paperwork as usual.
Tapes
are shipped to Haystack for correlation, unless the experiment has some
special spectral-line processing that must be done at Socorro. Note:
Thick
tapes not accepted at AOC.
Loading monitor data into the database (mon2db and fs2db)
Description: Monitor data is recorded in a file at each station during
a VLBI
project. This data has to be loaded into the VLBA_MON database. It
contains information that will eventually be used to generate
correlator job scripts.
- Current VLBA mondata is loaded automatically by Barry Clark's
cron job.
Old VLBA mondata is restored by Peggy Perley and we load it. We FTP
the foreign station Mark IV logs to vlbiobs and load the mondata for
each Mark IV station log with fs2db.
-
Check if data is already loaded by using dbreports. Use a
date
range spanning the four previous days and the day after the
observation's
time range. If data for all stations for the entire time range is
listed,
data is loaded. If data appears missing for a station or a time range,
load this data by itself. (mon2db will crash if it tries to
load
data that is already loaded.)
-
Check if mondata is in either /jansky/mdata or /jansky/mdata2
or /dopey/MONDATA. Contact Peggy Perley if you have questions
or need the data restored.
-
Monitor data can be loaded by two different programs, depending on the
type of monitor data. mon2db is used for VLBA-type
mondata,
while fs2db is used for Mark IV-type mondata.
mon2db
- cd /home/vlbiobs/astronomy/<mmmyy>/<project
code>/jobs/ .
Logs from the mondata loading will be put in this directory.
-
Run mon2db with ANTENNAS, UTTIMERANGE, and MONDATAPATH set to
appropriate values. More than one antenna can be loaded at a time.
fs2db
- This program will only work on log version 9.1 and higher.
The version
of the log is listed on the first line of the file.
-
Run fs2db. SESSION should be correct. UTTIME should encompass
the observation. POLAR should be left as *.
-
If gaps in the mondata are detected and can't be filled (due to
problems
with mon2db, fd2db, the mondata, or the database),
talk
to Barry Clark.
-
If the VLA was involved, tell Barry so he can fix the frequencies if
the
project is multi-freq, or use editobs if it's mono-freq.
Making database repairs (editobs)
Description: Whenever there are errors in the VLBA_MON database, the
program editobs can be used to fix many of them. Otherwise,
Barry Clark will have to assist.
- editobs should now be able to run from the analysts'
account. It can fix the frequencies for
the VLA, enter the pad number for a single dish VLA observation, or be
used to fill mondata gaps by 'shadowing'.
-
For fixes to the VLA mondatabase, ANTENNA should be 'Y' and the
UTTIMERANGE
should include the entire timerange of the project. DATABASE
OORT:VLBA_MON,
BARREL_ROLL *, LOFREQ 0.
-
To correct VLA frequencies, the entire observation must use only one
frequency
set. Otherwise see Barry Clark. Find a VLBA station that observes
during
the time the VLA does and set COPYFREQ to that station, TELESCOPE *.
For example:
- copyfreq LA
-
telescope *
-
go
-
q
-
To enter the pad for a VLA single dish observation, first determine
from
the observation logs which antenna was used. The default entry in the
database
is the phased array, Y27. The standard antenna is 27, at pad N8. Set
TELESCOPE
to pad ID. COPYFREQ *.
For example:
- copyfreq *
-
telescope YN8
-
go
-
q
-
To patch mondata gaps, ANTENNA should be the station with the problem,
UTTIMERANGE should start at the beginning of the first
corrupted/missing
scan and end at the end of the last corrupted/missing scan. SHADOW
should
be a nearby station with mondata. Shadowing should be used cautiously
in this current era of tape autoallocation.
For example, to fix LA with PT:
- ante LA
-
shadow PT
-
go
-
q
Adding sources to the database (OMS and fillsources)
Description: When you need to add VLBA source coordinates to the
auxiliary database use OMS or fillsources.
There are two tools to add source coordinates to the database: OMS
and fillsources. For a limited number of sources (1-3), OMS
is useful. OMS can also be used to view sources already in
the database. For more than a handful of sources, fillsources
is better. A fillsources input example file is in /home/vlbiobs/astronomy/seds.
fillsources
- Construct an input file on vlbiobs in the project's
directory (i.e. /home/vlbiobs/astronomy/<mmmyy>/<project
code>) that follows the format of the example file (/home/vlbiobs/astronomy/seds/fillsources.in).
-
If the PI does not request special coordinates, the source rows for the
input file can be copied from the end of the project's .sum
file
in /vlbiobs/astronomy/mmmyy (for projects after nov97 only).
-
If the PI requests special coordinates in the prod response, those
coordinates
MUST be in the EXACT format as in the example! Save the prod response
to
a temporary file and cut/paste the coordinate rows into the input file.
-
Run fillsources < input file. The program will
return
messages as it runs. Compare the number of sources it reports at
completion
to the number of source rows in the input file.
Updating clocks database (mon2clock)
Description: Clock value offsets (differences between the station
maser and the local gps receiver) are recorded daily at many VLBA and
foreign stations. These offsets are tabulated and used to calculate
clock offsets and rates listed in the job scripts and used by the VLBA
correlator.
- SSH to an analysts window on shire.
- cd to /home/shire/vlbaclocks (aliased to "clocks")
-
cd /yyyy/vlbaclocks (aliased to "vlb").
-
Run mon2clock. (-h flag provides help.)
-
Plots of delay vs. time will appear on display. Click on plot to find
the
corresponding date. Click on INSERT to add solution to database and
continue
to the next station, or SKIP to just continue to the next station.
-
mon2clock will try to break delay fits when the
standard deviation
(SDEV) exceeds 1.5e-07. A minimum of 2 points are needed to detect a
break.
-
A <run date>_Clocks.SQL, .MAIL, .SUMMARY and .LOG
file will be produced along with Postscript files of each plot.
- .SUMMARY contains offset and rate information.
- .LOG file contains text of entire run of mon2clock.
-
.MAIL file contains epoch and version information
for each station.
-
.SQL file includes SQL commands. These
commands are
not necessary
if INSERT was used for all stations. This needs to be mailed to
labeyta, arascon, jromney, mclausse, mstanley, and jops@jive
(aliased to "clocks"). "send" will email summary file.
- ex: "send clocks" will email summary to all recipients listed in "clocks"
-
Print .MAIL, .SUM and .ps files and put them in the
VLBACLOCKS
book. ("prtclks" will print all of these files)
-
Mark calendar two days after the date you ran mon2clock. The
clocks
are good to this date.
Updating Foreign Clocks
- In /home/shire/vlbaclocks/yyyy/evnclocks (aliased to "evn"), run "getevn".
-
getevn will collect gps files from EVN server and place them into a mmmdd sub-directory. cd
into
it.
- If there is a file for Effelsberg, EB (gps.eb), it can be
deleted as this is the VLBA terminal and will be processed with monitor
data. gps.ef is the Mk4 terminal and can be processed with other
foreign station gps files.
-
Run mon2clock -i gps.fs <foreign station> . "gpsclks" will loop all files found through mon2clock -i.
- "prtclks" will print MAIL, SUMMARY, and plot files for filing in FOREIGN CLOCKS notebook.
Pre-Production
Determining foreign clocks (clock searches)
Description: Foreign station clocks (non-VLBA sites) need to be check
or found before they are correlated. Foreign station clocks tend to
be less stable than VLBA clocks which warrant clock searches.
- Information on stations, observation schedule, and
observation mode can
be found in the project's .brg, .drg, and .sum
files. From these files find scans on a bright, compact source or two.
(A list of good calibrators is in the works. Refer to the VLBA help
tables
[/users/analysts/help/vlba.tables] or choose a VLA A-array
P-class calibrator stronger than 3 Jy at the correct band from the VLA
calibrator list.)
-
Write up one or two short jobs that include scans on the chosen
calibrator.
Use only the foreign stations and the 2-3 nearest VLBA stations, all
channels,
spect. ave. = 1, fftsize = 512, 1024, or 2048, and time ave. = 2. Use
job series xx01-xx19,
these job numbers are dedicated to tests and clock searches. (See "Writing
VLBA Correlator Jobs" for info on making jobs.)
-
Make a dummy job script with all stations in the project, a timerange
that
includes a scan with all stations, and default values for the other
inputs.
-
Copy the clocks.sed file in /home/vlbiobs/astronomy/seds
into the project directory. Use the
rows from the clock table in the dummy job to replace the row in the clocks.sed
file. Set the delay and rate in clocks.sed for the foreign
stations
to zero, if they aren't already (except the delay for the phased array
VLA should be -2.4e-04, and the delay for CA should be -9.5e-04). Set
the
time to 0h00m00s, and the date to the first date of the observation.
Apply
the sed file to the jobs (see "Using sed scripts"
for
instructions).
-
If possible, sign up for an hour or two of correlator time during the
day
and have your jobs run. If you can't find time during the day, have the
jobs run during the night's queue. Watch for low weights or other
playback
problems in the foreign station tapes. (Several foreign stations have a
history of record problems.) Take these problems into account during
the
next steps. Have the FITS file(s) from the job(s) distributed to the
terminus3
or abacus3 FITS area (/terminus3/AIPS/DA01/FITS or /abacus3/AIPS/DA01/FITS).
-
cd into the sniffer/ directory under the
main project directory. Make a clocks/ subdirectory.
cd into the subdirectory and make additional
subdirectories for
each clock search job to be looked at.
-
Run fringex <FITS file with full path> <reference
antenna>.
If the data is on a tape then run fringtp<AIPS number of tape
drive> <reference antenna> ALL <file number> <file
number> (example: fringtp2 PT ALL 1 1).
The refant should be one of the VLBA stations included in the clock
search
job. fringex or fringtp will produce an apdfile.ps,
an
acbandfile.ps, a xcbandfile.ps, an
acbandfile.lis, a xcbandfile.lis, a datafile.lis,
and a logfile.lis. WARNING: These sniffer scripts
will write
over previous plot files in the current subdirectory, so be careful
when
re-running fringex and fringtp.
-
Run gv apdfile.ps to view the output. Each group of plots is
for
one baseline (pair of antennas). The plots (from top to bottom in each
group) are fringe rate, fringe delay, fringe phase,
and fringe amplitude. The delay and rate plots should have low
noise,
that is the full range of values on the left of the rate and delay
plots
should be no more than 5-10 mHz and 40-50 ns, respectively. In other
words,
the data points plotted should not be scattered over a large range of
values;
they should approximate straight lines, rather than a scatter of points.
-
If the entire timerange has a rate range of 100's of mHz and a delay
range
of 1000's of ns, then something happened in correlation and the data is
potentially useless. First rerun fringex with a different
refant,
preferably closer to the unknown station, even if that means using a
foreign
station as a refant.. If that doesn't work, check over the job in
question
carefully:
-
Were there any comments in the telescope operator's log (refered to as
Mark IV logs for foreign stations) about problems
for that timerange? (These are usually in the project directory.
They're difficult to read but can be useful.)
-
Were there any comments in the operator's log about poor playback or no
synch-up? If so, you should try another timerange or find offsets
first.
(See "Finding head errors (offsets)" for info.)
(The log can be found on /home/reber/vlbacorr/logs.)
-
Are the values in the clock table for the foreign stations what they're
supposed to be? (-2.4e-04 for phased VLA, -9.5e-04 for CA, zero for all
others)
-
Are the station positions correct? (This can be checked against the
Eubanks
station list somewhere in the office.)
-
Does the frequency structure make sense? (No zero frequencies for all
IFs,
zero bandwidths, frequencies that lie outside the observable bands,
etc.)
-
If only part of the timerange shows fringes, run plotapd
using
that time range. The input file (the first question in the program) is
datafile.lis.
Name the output file something other than apdfile.ps or plotapd
will overwrite the original (example: apdfile2.ps/vps).
-
Once the plots are satisfactory, estimate the average value of the
delay
and rate for each foreign station. The delay should be ADDED to the
value
already in clocks.sed. The rate should be divided by the
observing
frequency for that scan, then ADDED to the value already in the clock.sed
for that station. There is an added complication if you found fringes
with
a non-VLBA station with unknown clock as refant. You must not only add
the delay/rate of the unknown station, but also the delay/rate of the
foreign
refant, too, to the value in clocks.sed. Also, the value of X
referenced to Y is the negative of Y referenced to X. (Useful if you
find
a station by using it as the reference antenna.)
For example: If you found MC referenced to EB (say delay =
-1.2e-06 s,
rate = -1.0e-14), and EB referenced to HN (say delay = +5.4e-06 s,
rate = -3.2e-13), then MC referenced to
HN would be delay = +4.2e-06 s and rate = -3.3e-13. Additionally, if
you had made
an initial guess (perhaps from GPS data) for the MC delay of -11
microseconds (=
-1.1e-05 s), then the delay value in the MC row in clocks.sed
should
be changed to -6.8e-06 (-1.1e-05 + 4.2e-06).
- Last, if fringex is failing you, start AIPS and
load the FITS
file with task FITLD with parameter WTTHRESH = 0. If you used
more than one IF channel,
split one from the data using task UVCOP. Use task DTSUM with
parameter APARM = 0
to get the timerange of the calibrator, the antenna numbers, and the
integration
time. Then use task FRING or with these settings: REFANT = a VLBA
antenna,
SOLINT = ~2, APARM(6) = 1, APARM(7) = 7, DPARM(1) = 1, DPARM(4) = the
integration
time. You can see if FRING is finding anything by watching the
delay
and rate from the output; if the SNR (signal to noise ratio) is high
(>7),
the solutions are usable. If there is still no solution try splitting
another
IF and trying it. Once FRING is done, use SNPLT and set OPTYPE =
'DELA'
and 'RATE' to look at the solutions. Read the delay and rate
values
off as before and modify clocks.sed.
-
If you are still having problems, talk to Vivek Dhawan, or whoever
is in-house contact for the project.
Finding head errors (offsets)
Description: Occasionally, a station tape has the tracks written so
far off from where they are supposed to be that the correlator
playback drive can't find the right track. This is an old procedure
for finding where the heads (tracks) should be.
- Head errors are routinely added to the database for the
following stations:
EB, GB, JB, MC, MH, NT, ON, and WB. You only need to find head errors
if
the project was observed before June 1993, or includes stations other
than
these.
-
Look over the schedule files (.drg, .sum, etc.) for
a
long timerange that includes all the stations that need offsets found.
-
Make a job several hours long that includes this timerange. Don't worry
about the parameters or clocks, the job just needs to have many
recorder
rows for each station. Be sure that the VSNs are correct.
-
Rename this job job<project code>.off and put a copy in
the /home/reber/vlbacorr/offsets
directory.
-
Send mail to vlbacorr asking for offsets to be run for the
stations
in that job.
Writing VLBA Correlator Job Scripts (SUB2DB, CORRELATE,
and CJOBGEN)
Description: When a VLBA project has observed, the analysts
are in
charge of creating the correlator job script files. These 'jobs' are
the instructions needed by the correlator to playback the station
tapes and correlate the data. There are a number of programs and
scripts the analysts use to create these files.
- Notes, special parameters or coordinates, and file names
should be recorded
on a job check-list. Fill out the check-list as completely as possible,
as it will allow you or another Analyst to follow what you have done
days
or weeks later. (An up-to-date version of the checklist is /users/analysts/help/jobcheck.)
-
The parameters for correlation can be found in the .sum file in the
project directory on vlbiobs. Look for parameter changes or special
requests in the project directory or in the project folder. Special
requests for source coordinates should be added to the database
FIRST! Use fndsrc.pl to find any other sources that need to
be
added to the Auxiliary source database. Use srctool or fillsources.
-
Open a reber window and login as vlbacorr. Type nlj to get a
numerical
listing of job series and alj for the job series listed
alphabetically
by project. Any job series between 2000 and 9900 not listed by nlj/alj
is free to use. Assign it to your project by cd'ing into that
directory and using touch <project code>.<YYMMDD>,
as in
touch
BA001.960101. This will create an empty file with that name.
Another
nlj will show that your project is now using that job
series.
-
Open a analysts owned window and cd
/home/vlbiobs/astronomy/<mmmyy>/<project>/jobs/orig/.
All job creation work should be done inside the jobs/
directory
with the orig/ subdirectory as the area where the jobs are
initially generated by CJOBGEN.
-
Create a touch file in the jobs/ directory on
vlbiobs. (Example: touch <project code>.<YYMMDD>)
-
Words of warning:
-
The VLBA Correlator cannot handle 1:4 fan out, 2-bit, polarized data as
of July 1, 1996.
-
An output rate of more than 500 kB/s has not been tested. This limit is
not firm, but should not be greatly exceeded.
-
Jobs should have an output file size of ~1 GB or less.
-
In the project's directory on vlbiobs, run sub2db.
This program
looks through all the project's mondata and assigns stations to
subarrays,
if any exist. Even if you know there are no subarrays in the project, sub2db
must still be run to assign all the stations to the same subarray and
construct
frequency setups. It produces an enormous output text,
saved as <project code>Sub.txt.
The following parameters are important:
- PROPOSAL must be set. Remember to leave out the segment
character.
-
UTTIMERANGE must be set. Start the time range about 12 or 24 hours
before
the project begins and end the time range about 12 or 24 hours after
the project ends.
The rest should be left alone, unless Barry Clark tells you otherwise.
- Run correlate. This program stores the
correlation parameters
for clock searches, tests, and production.
The following parameters are important:
- PROPOSAL must be set. Remember to leave off the segment
character.
-
UTTIMERANGE should be the same as was used in sub2db.
-
STARTJOBID is XX01 if you are making clock searches or tests, XX20 if
you
are making production jobs. Here XX is the first two digits of the
job number series for the project.
-
NUMBERJOBID is 19 if you are making clock searches or tests, up to 80
if
you are making production jobs.
-
FFTSIZE can be 512, 1024, or 2048 if POLAR is NO and must be 256 if
POLAR is YES.
-
INTEGRATIONTIME and SPECTAVG should be 2 and 1, respectively, for clock
searches, or they should match the values given on the parameter sheet
for the project for production jobs.
-
POLAR should be NO for clock searches, YES only if it is requested on
the
parameter sheet.
-
WINDOW is the only other parameter you should change. It is either
UNIFORM
(default) or HANNING.
LEAVE THE REST ALONE (Unless you know what you're doing.)! Once all the
parameters are set (use inp
to look at the parameter list), type go put (typing just
go will result in an error message). Record what row
these
parameters have been assigned to. You'll need the row number for the
next
step. (If you need to edit the row or need to reset the jobid pointer
back
to the beginning, use go get until it restores the correct
row,
edit what you need, then use go replace to put those
parameters
back into the same row.) The go put, go get, go replace
commands are needed to help manage multiple correlation rows if the
need arises.
- Run cjobgen. This program accesses the
monitor database and constructs
correlator jobs.
The following parameters are important:
- PROPOSAL must be set. Again, drop the segment character off
of the
project code.
-
UTTIMERANGE should be set to approximately the time range of the
project.
-
CORRELATION should be set to the row number from the previous step.
-
PASS should be *, unless you have added sources with more than one
cqual
and you want jobs for only one cqual.
-
ANTENNAS should be *, unless you want to select certain stations for a
clock search or test.
-
CHANNELS should be *, unless you want to select certain channels for a
clock search or test.
-
DATABASE should be left as VLBA_MON, unless you are making some sort of
test.
-
JOBID should be * for production, or you can specify a particular jobid
and only that job will be made.
-
SINGLETAPE should be left YES.
-
JOBLENGTH should be 1.5 (hours).
-
OUTPUTSIZE should be 660(MB).
-
GAPSIZE should be 7 (minutes).
-
PRIME should be 20, unless scans are shorter than a minute, then it
should
be changed to 0.
-
TABLES should be set to ALL so that calibration files are created
along with the jobs. These files have the format: XXXX0001.CL,
where XXXX
is the job number.
It is useful to save the comments cjobgen produces while it
is
running. A good place for them is an output file in the
project
directory.
- Copy the job scripts and calibration files up into the main
jobs/ directory (i.e. cp j* ../)
-
cd ../ next. All job modification is done is this
directory.
- Create a touch file in the jobs directory with the format
PROJE.YYYYMMDD.
-
See "Using sed scripts" for info on making changes
with sed scripts.
-
Once you have made any necessary changes and checked those items at the
bottom of the job construction checklist, you can copy these jobs and
calibration
files to reber. First, you must change to the vlbacorr account (type:
su vlbacorr). Use cp <list of jobs>
../../../joblink/<job series>,
as in cp job2000.fx ../../../joblink/2000. Then exit from
the vlbacorr account (type: exit).
-
If you have made production jobs with any foreign stations, a pilot
needs
to be run first. Pick a job that includes all the foreign stations and
as many of the VLBA stations as possible and have that run first.
Analyze
the data from that job. (See "Sniffing data.") If
you find residual delays smaller than 250 ns to the foreign stations
the
rest of the production can be put into the queue, otherwise you'll need
to investigate why your clock searches didn't work.
-
E-mail Steve Thompson at vlbacorr and inform him the jobs are
ready to be run. The Email must include the entire project name
including the segment character, the job numbers, the correlator area
(usually code unless you're running a special correlator test), and
any special instructions. His deadline for jobs for that night's queue
is 4:00pm.
-
Copy the job checklist and place the copy in the checklist binder.
Update the analysts' queue file at /users/analysts/vlba/
Instructions for Setting Up the Correlator Pulsar Gate
Description: For VLBA pulsar experiments, the pulsar signal can be
improved by cutting out all the data except when the pulsar is
'pulsing'. This can be done in the correlator by using the pulsar gate
and an accurate model of the period of the pulsar's beam.
- - Use EDITOBS to set the source calcode to 'G' for the
pulsars. The observer
may have set the calcode = 'G' when he ran the SCHED program, but don't
count on it.
-
- Load the user supplied polyco.dat
file(s) in the database 'polyco' table. Use the program 'POLYCO2DB'.
The
polyco.dat
file may need to be edited first. Generally the pulsar name in the
polyco.dat
file is the B1950 name, like 1133+16. But the pulsar name used during
the
observation and thus in the monitor database is the J2000 name,
J1136+1551.
You will probably need to replace the B1950 name with the J2000 name in
the polyco.dat file.
-
- Set the pulsar gate on phases and off phases in the database 'gate'
table.
Use the program 'GATE2DB'. Different on/off phases are allowed for each
observing band. Eventually we expect perfect pulse phase predictions
from
the observers (the polyco.dat) file. When this is the case, the on
phase
and off phase should be set to 0.975 and 0.025 respectively. This opens
the gate for 0.05 of the pulse period centered on pulse phase of 0.0.
The
frequency parameter in GATE2DB can be set to zero for now.
-
- Run the 'CORRELATE' program and set PULSAR_GATE = YES.
-
- Run SUB2DB. The pulsars are recognized by the 'G' calcode and listed
on the screen.
-
- Run 'CJOBGEN' normally. A 'Gate Table' is inserted in the job script.
There will be rows in the Gate Table for those sources (pulsars) whose
calcode = 'G'. CJOBGEN produces a new row every 15 minutes.
Using Sed Scripts
Description: There are various shell command scripts (SED, AWK, PERL)
that can be used to modify job scripts. Modifications usually
need to be done on the clocks table, offsets table, or station VSN and
shelf locations.
- Examples of the various sed scripts are in /home/vlbiobs/astronomy/seds.
Copy the appropriate file to the project jobs/ directory, or
use the file as a template. The clocks.sed, vsn.sed,
and offsets.sed files must be modified for use:
-
Incorrect VSNs in the jobs can be corrected with vsn.sed. VSN
information can be found using track -w (menu item b.
followed
by menu item e.). The vsn.sed file has the format:
/2-letter station code/s/wrong VSN/correct VSN/g.
Shelf locations
can be similarly changed using shelfloc.sed or vsnshelf.sed.
-
Incorrect or missing clock delays and rates can be corrected/added with
clocks.sed.
Clock delay and rates can be found (See "Determining foreign clocks")
or
will be in a sed script that someone else has constructed (normally
named
clocks.sed). REMEMBER to follow the format in the
example .sed
EXACTLY!! The known clocks for the VLBA antennas need to be copied from
a job. (Make a dummy job that includes all antennas and cut the clocks
table out). The clocks.sed REPLACES the clock table in the
jobs
with the rows in the sed script. ALL stations in the project
must
be included in the clocks.sed or they will be left out!
-
Head errors (offsets) can be corrected/added with offsets.sed.
Have each station's offsets found (See "Finding head errors
(offsets)").
The results are reported in /home/reber/vlbacorr/offsets/<project
code>. Construct a file called <project code>.off
in the
/<project
code>.</jobs/ directory with the format like the /home/vlbiobs/astronomy/seds/offsets.sed
file. There are comment lines in the file to help explain its use.
-
Run consed <list of .sed's> to construct a run file
that will
apply the sed scripts to the jobs. A file ending in .in will
be
created. Run this file by typing its name; it will apply the sed
scripts.
WARNING: consed will ask for the beginning and ending jobs
for a series of jobs. If non-existant jobs are included in this job
number range, the sed script made by consed will create dummy
jobs for
the missing job numbers.
Post-Correlation
Sniffing data (FITSsniffer)
Description: The data analysts and the scientific scrutinizers check
the tapes with the final correlated data for problems after
correlation. This helps in determining the health of the array,
spotting correlation mistakes, and gathering helpful information for
the observer. If everything looks OK, the VLBA station tapes can be
degaussed and sent back to the sites.
- Fill out the top of a "DATA CHECKOUT" checklist from the
information provided
on the project tape distribution log and on the job checklist.
-
cd /home/vlbiobs/astronomy/<mmmyy>/<project
code>.
- Make a copy of the proposal cover-sheet for the project and
place
it in the project folder. The cover-sheets are usually found in the
folder cabinet in the analysts' office.
-
A sniffer_srcs.lis file needs to be made of the format listed
in Item #3 on the checklist. The sources for a sniffer_srcs.lis
can be found in the project's .sum file and compared to our
calibrator
list. You need to include at least one good calibrator in the sources
to
be sniffed. The sniffer programs handle data in two ways, LINE and
CONT(inuum).
The only difference is in the apdfile.ps (See below.)
-
If this is production and there are multiple tapes, a seperate
directory
must be made for each tape, since fitex will overwrite the
files
from the previous tape if it is run in the same directory.
-
To run fitex, cd into the appropriate subdirectory
below
the project directory, be sure the tape is loaded and type fitexn
<refant> <ALL or LIST> <first file on tape to be
processed> <last
file on tape to process>, where n should match the AIPS tape
number
of the drive you're using, ALL should be used to process all sources,
and
LIST should be used to have the program read the sniffer_srcs.lis
file in that directory. For example, to read files 3-7 on a tape in
AIPS
Tape Drive 2, with reference antenna HN, and using a sniffer_srcs.lis,
you should type fitex2 HN LIST 3 7.
-
If this is a trial, mkd trial, then cd trial. If
the
trial data is on disk, run fitdsk <full path to FITS file>
<refant>.
If the trial data is on tape, load the tape and run fitexn
<refant>
<ALL> 1 1, where n should match the AIPS tape number of the
drive
you're using. For example, fitex1 HN ALL 1 1, if you loaded
the
tape into your machine's first drive and the data is the first file on
the tape.
-
Once all tapes have been sniffed, start gv and look over the wtsfile.ps,
acbandfile.ps,
xcbandfile.ps, and apdfile.ps plots for
problems. Note
any problems or questions on the checklist. Specifically check:
-
wtsfile.ps:
-
Gaps that can't be explained by the schedule or by entries in the
Operator's
log.
-
Very poor weights may be improved by re-running that job with the
affected
tape on a different PBD. Check the correlator operator's log to see if
they tried. (The electronic and operator logs can be found in /home/reber/vlbacorr/logs.)
-
acbandfile.ps:
-
Very large spikes that dwarf the amplitude of the rest of the band in
one
or more IF indicate RFI, if it isn't a line source.
-
Multiple, small, uniformly-spaced spikes are from the internal phase
calibration tone generators (pcals).
-
Dead or low amplitude bandpasses can be from dead tracks on the tape or
dead receivers at the site.
-
Odd bandpasses may be a sign of internal correlator trouble or may be a
sign that the observation was near the edge of the observable band. (A
normal bandpass is nearly flat in the middle with steep sides.)
-
xcbandfile.ps:
-
Each baseline should show fringes for at least one scan.
-
Very large phase slopes indicate large residual clock delays.
Cross-check
this with the apdfile.ps plots.
-
Odd bandpasses may be a sign of internal correlator trouble. (A normal
bandpass is nearly flat in the middle with steep sides.)
-
apdfile.ps:
-
NOTE: The delay data has a different meaning depending on whether the
source
was processed as LINE and as CONT. In CONT mode, the delay data is
really
delay data, while in LINE mode, the delay data is actually the channel
where the program has detected the spectral line.
-
Each baseline should show fringes for at least one scan, hopefully the
same scan that showed fringes in the xcbandfile.ps plots.
-
The sniffer scripts envoke another script called lister. This
program
will read the datafile.lis file and produce a file called summary.
Look in this file to check if polarization is ON and to make sure the
requested
coordinates were used.
-
Hand the folder with the checklist and the tape(s) to the contact
person
listed on the VLBA schedule. Ask them if they can release the project
within a week. If they say they can't, take the folder to Joan Wrobel
who will find a scrutinizer who can.
-
Update the analysts' queue file at
/users/analysts/vlba/. Update schedules by
noting the one week release date.
Projects That Can Be Release by Data Analysts
(DAR)
Description: If a project has no correctable problems and meets
certain criteria, then the data analyst can scrutinize and release a
project without passing the project on to a staff scientist.
- The conditions under which a project can be released by a
data analyst
are:
-
The project is a continuum observation.
-
The project has many bright, point-like sources if it is a 7mm
project.
-
The project has no serious or correctable problems with the data.
-
Projects that should be given to a staff scientist to scrutinize are
all spectral line projects, RDV projects, CMVA projects, Gated Pulsar
projects, SGA astrometry projects, and others.
-
Review the System Temperature, Weather and Pcal for anomolies and
record or report such anomolies in addition to problem found while
sniffing.
Dear PI Letters and Shipping Data Tapes (Project
Release)
Description: The following are procedures on how to create a final
Email summarizing the correlation and how to send out the correlated
data tapes.
- Once the scrutineer has given their OK, a "Dear PI" letter
can be made
with piletter, which can be run from any window owned by
analysts.
The program is interactive and self-explanatory.
-
The "Data Tape Distributed To:" and "Date:" at the bottom of the Tape
Release
Form should be filled in. Then the folder can be given to Dave Medcalf
or Robyn Harrison.
-
If the letter is printed in piletter, two copies will be
produced.
One should be put in the project file, the other included with the tape
and TSM plots to be shipped to the PI.
-
Shipping is handled the same as VLA data tapes. Be sure to note that
the
tape(s) contain VLBA data.
-
Once the tapes are released, make sure all correlated jobs are on
vlbiobs. Then delete the jobs off of reber. Finally, gzip all files
in the project directory on vlbiobs as vlbiobs.
-
VLBA CJOBGEN CHECKLISTS of projects that have
been released should be filed alphabetically in the VLBA
project folders in the top drawer of the filing cabinet.
Cleaning up reber once projects have been released
Description: There are only one hundred unique job series numbers, so
they need to be constantly recycled.
- Approximately every month, old job series corresponding to
released projects
need to be cleaned off of reber. Released projects will have an entry
in
/users/analysts/vlba/queue.his.
-
After logging into reber as vlbacorr, cd to the jobs
directory, and do an alj to see occupied job series.
-
If a job series is occupied by a released project, cd into
it, and delete all the files in that directory including the
touch file.
VLBA data redistribution
Description: Procedure for sending out VLBA data from past
observations.
- If someone requests old VLBA data, clear it with Joan Wrobel
first
then forward the request to Steve
Thompson (Date of observation, date of correlation, and job numbers are
very helpful to him), and wait for a correlator operator to bring you
the new distribution.
-
Check the job numbers, the project code, and the date to make sure
they are the right jobs on the tape.
-
Load the tape or tapes onto a tape drive. Run a script called cktp<AIPS
tape drive number>
(i.e. cktp2 for a tape in AIPS tape drive 2). This script
runs the dd command and is useful for checking for tape
defects.
Let Bruce Rowen know of any problems with reading the tape, and get
another distribution if there are real problems with the tape.
-
Fill out an AOC Shipping Form and send off the tape.
General Analysts
Tasks
Workstation Backups
Description: It's a good idea to backup your workstation
for
safety's sake.
- The disks of each analyst workstation should be backed-up
periodically.
- To backup small hard disks (< 3Gb), load a blank tape into
an
exabyte drive and cd to the main directory of that disk. Use:
tar cvf /dev/rmt/0lbn *. The backup will
take a few
hours and slow down the machine a little.
- Store the tapes in the tape cabinet located in office 201.
- For large disks that will require several tape volumes, more
exotic versions of tar or gtar need to be used.
White Board Management
Description: We keep a couple status boards in the large
office to
help us visualize what projects need to have jobs made or sniffed and
what other tasks need to be done or are already completed. It also
helps us keep tabs on who is doing what.
- The large main white board reflects what is being addressed
or needs
to be addressed such as sniffing, job making, SCHED files, and other
tasks.
-
This board is cleaned-up and organized once a week (usually Monday
morning).
-
The board should be updated frequently.
NRAO Birthday Cake Day
Description: Eat cake.
- On the second Wednesday of every month at 2:00 pm, all
analysts must
process to the upstairs common room and eat birthday cake and ice
cream.
-
If an analyst missed breakfast or is particularly hungry, he/she can
have seconds.
Back to the Top
Go to Analyst
Observing Notes
Go
to VLA Special
Topics and Observing Modes
Go to NRAO Homepage
Document originally compiled by Kevin Healy, 1995, 1996.
Last modified by Jason Wurnig on June 25, 2000.
INTRODUCTION
VLA Jobs
VLBA Jobs