You are here: NRAO Public Wiki </wiki/bin/view/Main/WebHome>>GB/Software
Web </wiki/bin/view/GB/Software/WebHome>>ModificationRequest1Q412
<https://safe.nrao.edu/wiki/bin/view/GB/Software/ModificationRequest1Q412>
(2012-11-02, PaulMarganian </wiki/bin/view/Main/PaulMarganian>)Edit wiki
text
<https://safe.nrao.edu/wiki/bin/edit/GB/Software/ModificationRequest1Q412?t=1352299975;nowysiwyg=1>
Edit
<https://safe.nrao.edu/wiki/bin/edit/GB/Software/ModificationRequest1Q412?t=1352299975>
Attach </wiki/bin/attach/GB/Software/ModificationRequest1Q412> Print
version </wiki/bin/view/GB/Software/ModificationRequest1Q412?cover=print;>
Support Phase I of PAF Integration
Modification Request 1 (Q4 2012)
* 1. Introduction <#A_1._Introduction>
* 2. Background <#A_2._Background>
* 3. Requirements <#A_3._Requirements>
* 3.1 Requirements for the Config tool during the testing and
evaluation PAF phase
<#A_3.1_Requirements_for_the_Config_tool_during_the_testing_and_evaluation_PAF_phase>
o 3.2 Out of Scope <#A_3.2_Out_of_Scope>
* 4. Design Strategy & Summary <#A_4._Design_Strategy_38_Summary>
o 4.1 Overview <#A_4.1_Overview>
o 4.2 PAF Manager <#A_4.2_PAF_Manager>
o 4.3 Socket Interface <#A_4.3_Socket_Interface>
+ 4.3.1 GPIB <#A_4.3.1_GPIB>
+ 4.3.2 AD <#A_4.3.2_AD>
o 4.4 Config Tool <#A_4.4_Config_Tool>
o 4.5 Data Products <#A_4.5_Data_Products>
o 4.6 Miscellaneous <#A_4.6_Miscellaneous>
* 5. Example Observing Session <#A_5._Example_Observing_Session>
* 6. Deployment Checklist - For sponsor and/or software engineer
<#A_6._Deployment_Checklist_45_For_sponsor_and_47or_software_engineer>
* 7. Test Plan <#A_7._Test_Plan>
o 7.1 Internal Testing - For the software engineer to fill out
<#A_7.1_Internal_Testing_45_For_the_software_engineer_to_fill_out>
o 7.2 Sponsor Testing <#A_7.2_Sponsor_Testing>
o 7.3 Integration/Regression Tests
<#A_7.3_Integration_47Regression_Tests>
* Signatures <#Signatures>
* CCC Discussion Area <#CCC_Discussion_Area>
1. Introduction
The PAF is a new 1.4-GHz, cryogenic, phased array feed for the GBT.
Considerable infrastructure needs to be added to the GBT to accommodate
the relatively large number of receiver channels, and the data rates are
potentially quite large so the system definition will include everything
from the array elements to data archiving and system control. The system
design is a work in progress.
Development work for this project has been a collaboration between
Brigham Young University and NRAO, and this work continues as the
definition of an array for the GBT takes shape.
The objective of this MR is to describe the software changes needed to
be made to GBT software in order to accomodate this receiver in it's
first phase of it's testing on the GBT. This will be an investigator
only instrument (Rick Fisher's group); in other words no shared risk
observing - this will not be ready for full public use for a while yet.
The investigators have completed a system already for their 20m tests,
and the interface to this system should remain relatively unchanged
during this upcoming phase of GBT testing. However, in the long term,
changes are anticipated in this system.
Subsequent phases of development for this receiver may involve
significant changes, including incorporating such elements as FPGAs.
These next phases will probably require more involved design phase and
tighter integration with GBT software. We will not attempt to anticipate
these changes in this MR. Again, for this first phase we are attempting
to enable testing of the PAF on the GBT as quickly as possible, with as
little additional GBT software as possible.
2. Background
* PAF web page: http://www.cv.nrao.edu/~rfisher/PAFproject/
* System Design:
http://www.cv.nrao.edu/~rfisher/PAFproject/design/PAFsystemDesign_rev0.pdf
* See attachments for block diagrams of the system, and descriptions
of FITS formats used.
3. Requirements
Main requirement: investigators should be able to use the new PAF
receiver to run tests on the GBT.
* The new PAF receiver will be referenced by two names:
o internal representation: RcvrArray1_2
o public name (this can be easily changed in the near future, so
isn't much of a requirement?): PAF
* Investigators must be able to use Astird in order to:
o change specific PAF parameters
o change specific LO1 parameters
o execute scans
* PAF observations should produce FITS files in the standard format
(in /home/gbtdata) for the following devices:
o GO (created by Astrid)
o Antenna (created by Antenna Manager)
o LO1 (A or B) (created by LO1 Manager)
o PAF - including RcvrPAF and FXCorPAF as described in attachment
(created by PAF system).
* The start time for the next observation must be passed on from the
GBT system to the PAF system.
* PAF observations must be scheduled via the Dynamic Scheduling System
(like any other new receiver).
* The following PAF parameters must be tunable via astrid:
Parameter
</wiki/bin/view/GB/Software/ModificationRequest1Q412?sortcol=0;table=1;up=0#sorted_table>
Default Value
</wiki/bin/view/GB/Software/ModificationRequest1Q412?sortcol=1;table=1;up=0#sorted_table>
Legal Range
</wiki/bin/view/GB/Software/ModificationRequest1Q412?sortcol=2;table=1;up=0#sorted_table>
Units
</wiki/bin/view/GB/Software/ModificationRequest1Q412?sortcol=3;table=1;up=0#sorted_table>
rest_frequency 1420 1200 - 1800 MHz
3.1 Requirements for the Config tool during the testing and
evaluation PAF phase
This section lists the requirements and expected implementation for the
config tool for the RcvrArray1_2 for the testing and evaluation phase.
It was added on 10-9-2012 as a result of a meeting between Rick Fischer,
Paul Marganian, Bob Simon, Joe Brandt and Melinda Mello on 10-4-2012.
The result of this meeting indicated that marginal support should be
added to the config tool such that the LO1 setup for this receiver will
be performed by the config tool. This will enable the user to run scans
within ASTRID without first running a "dummy" configuration with a
randomly selected receiver and will minimize the number of setValue
commands required in an observation script.
* This receiver will not be included in the cabling file but the
receiver will be cabled from the LO to S5-J1.
* The config tool will set the LO1 switches such that S5-J1 is
connected to LO1A after a configuration is run. This will include
setting S4-1 S2-thru and S9-1.
* The config tool will set the LO1 parameter loConfig = TrackA_BNotUsed
* The config tool will set the LO1 B frequency and power levels to the
nominal values
* The config tool will set the LO1 parameter restframe to Local
* The config tool will set the LO1 parameter velocity to zero
* The config tool will set the LO1 parameter phaseCalCtrl = off or
useOffsets=0.
* The config tool will set the LO1 parameter ifCenter to a nominal
value of 3000
* The config tool will set the LO1 parameter autoLevel to 0
* The config tool will set the restfreq in the LO1 and the
RcvrArray1_2 manager to the value provided in the restfreq config
keyword. (specified in MHZ)
* The config tool will set the subsystemSelects in the ScanCoordinator
such that only the RcvrArray1_2 and the LO1 are included in the
device list.
* The config tool will set the subsystem in the LO1 coordinator to
include the LO1A and LO1B and to exclude the LO1 counter.
* The config tool will set the ScanCoordinator receiver parameter to
RcvrArray1_2
* Legal astrid Configure statements using the receiver will include
the kewyords receiver and restfreq. All other keyword value pairs
will be ignored.
3.2 Out of Scope
* Investigators must be able to perform maps with the PAF using
Astrid: this is being covered by Joe Brandt's MR.
* Creation of RcvrPAF and FXCorPAF as described in attachment - these
are created by the PAR system.
* Creation, maintenance and analysis of data products - this is the
responsibility of the PAR system.
* Any kind of feedback from the PAF other then the resulting FITS
files from a scan - in other words, no feedback parameters, or
samplers. (We're just going to do the C in M&C).
* Engineering Interface: no need for a new CLEO screen or equivalent.
If we go with our design plan (see below), CLEO's Device Explorer
should be sufficient.
* No changes to the IF Manager are needed.
4. Design Strategy & Summary
4.1 Overview
Our implementation follows the basic principle stated above: to enable
tests with PAR on the GBT as soon as possible, with as little software
effort as possible, while making sure we are setup for further changes
where this can be easily done. Thus, here's our basic plan:
* Create a new M&C Manager for PAF
* This Manager will communicate with the PAF via socket connections as
described below
* The configuration tool should except the PAF as a 'special case' in
which only the PAF manager, LO1 and Antenna managers are allowed in
the Scan Coordinator
In this way, an investigor could write a scheduling block in which any
non-default PAF parameter values could be set using Astrid's SetValues
(which could also be used to set the GBT LO1), and a scan executed via a
simple Track command (remember, creating Maps via Astrid for PAF is out
of scope here).
Here's what this more or less looks like:
PAFPhaseOne.jpg
4.2 PAF Manager
* name: RcvrArray1?
</wiki/bin/edit/GB/Software/RcvrArray1?topicparent=GB/Software.ModificationRequest1Q412>_2
* parameters:
o all the usual defaults
o What kind are the ones described in the requirements? Need to
read up more on how parameters work - especially in conjunction
with a scan. Rick says he needs to add a command such that we
send the PAF system the start time, and the system starts the
scan at that time.
* default values for parameters (as specified in requirements) will be
loaded via config file (as is standard).
* Device Explorer will suffice as the engineering interface to this
manager.
* How should the setting of these parameters trigger the actual socket
commands to be sent? Should the parameters themselves not do
anything, and separate parameters (dependent ones) do that once all
their dependencies are completed?
* I haven't done a lot of managers, but a style that I've followed in
the past that I like is to separate M&C functionality (parameters,
etc.) from code that simply interfaces with the hardware. By making
this separation of concerns, it may be easier to run various tests
(including unit tests) on the parts that just communicate with
hardware.
* Start Time: here's how I think it all works:
*
o the SC asks all it's children how soon they can start a scan
o Each manager calculates its estimate of when it can start in the
'sampleEstimatedStartTime()' method. For the PAF manager, the
default method in the Manager class will be used, which returns
'now'.
o all the child managers report estimates back to the SC
o the SC sets the scan start time as the latest of these times
o the start time then gets broadcasted to all child managers.
o so, our PAF manager will use the default start time of 'now'.
o the start time that the SC passes back to the PAF manager will
be the start time passed on to the PAF system.
* Links:
o https://safe.nrao.edu/wiki/bin/view/GB/Knowledge/HowToCreateAManager
o https://safe.nrao.edu/wiki/bin/view/GB/Knowledge/HowToCreateAManagerExample
o https://safe.nrao.edu/wiki/bin/view/GB/Knowledge/NewManagerIntegration
o https://safe.nrao.edu/wiki/bin/view/GB/Software/YgorManagerToyExample
o https://safe.nrao.edu/wiki/bin/view/GB/Knowledge/ManagerStateEngine
4.3 Socket Interface
Rick Fisher has decided to greatly simplify the interface to his system.
So the original requirements and socket interface have been greatly
reduced. The current socket interface described below is an interface
Rick has yet create. For the original requirements and socket interface,
see this wiki page's history
Block Diagram of the PAF system:
pf_blk_diag1.jpg
Below is Rick Fisher's specification of the socket interface to the PAF
system:
The subsystem control computers are presently papillon.ad.nrao.edu (port
50006) and paf1.ad.nrao.edu (port 50005). papillon controls a set of
GPIB instruments, and paf1 controls an A to D converter card on its own
bus and relays messages to nine other computers (paf2-paf10) identically
configured. Each of these computers has a terabyte drive for temporary
data archiving.
Here's the sequence of commands needed to execute a scan using the PAR
system:
* gpib server commands first, typically at the start of an observing
run, in any order:
o set_rest_freq
o mkdir (for the AD conversion)
* then, to run each subsequent scan:
o set_scan_start
4.3.1 GPIB
gpib_server.py on papillon
receives messages through port 50006, socket opened and closed for each
message. messages:
set_rest_freq(rest_freq)
argument derivation from configuration keywords or constant values and
argument format:
arg
</wiki/bin/view/GB/Software/ModificationRequest1Q412?sortcol=0;table=2;up=0#sorted_table>
derivation
</wiki/bin/view/GB/Software/ModificationRequest1Q412?sortcol=1;table=2;up=0#sorted_table>
format
</wiki/bin/view/GB/Software/ModificationRequest1Q412?sortcol=2;table=2;up=0#sorted_table>
rest_freq rest_freq ?
4.3.2 AD
9812_server.py on paf1
receives messages through port 50005, socket opened and closed for each
message. paf1 id permanently connected to paf2-10 at startup through
port 50011 relays messages to paf2-10 and executes these messages itself.
messages:
* mkdir(dir_name)
* set_scan_start(scan_start, scan_duration)
* close_adc() (we probably won't be using this, as this shuts down the
data acquisition executable and requires a manual restart.)
argument derivation from configuration keywords or constant values and
argument format:
arg
</wiki/bin/view/GB/Software/ModificationRequest1Q412?sortcol=0;table=3;up=0#sorted_table>
derivation
</wiki/bin/view/GB/Software/ModificationRequest1Q412?sortcol=1;table=3;up=0#sorted_table>
format
</wiki/bin/view/GB/Software/ModificationRequest1Q412?sortcol=2;table=3;up=0#sorted_table>
dir_name dir_name %s
scan_start scan_start ?
scan_duration scan length in seconds %3.2f
4.4 Config Tool
One of our requirements is that PAF observations on the GBT can be done
using Astrid. A scan cannot be done in Astrid unless the configuration
tool is used. Here are some options:
* Fake it: Make a call to the Confugation Tool passing similar
backends and frontends to the PAF, such as L band and the Spectrometer.
o Adavantage: can do this right now, no changes needed
o Disadvantage: we can't setup the Scan Coordinator (SC) the way
we really want - we'll have to then manually remove a bunch of
these devices from the SC.
* Make a special case: we did this in Mustang's early days. Basically
tell the Config Tool, hey, if this is PAF, then make sure that the
only devices in the SC are PAF, Antenna, and the LO1, remove
everything else.
o Advantage: sets up SC the way we want it through a simple call
to Confiigure in the Scheduling Block
o Disadvantage: we'll have to make an actual change to the config
tool.
4.5 Data Products
By using Astrid in conjunction with the new M&C Manager, we should be
able to run scans with the Scan Coordinator using this new manager, the
Antenna, and the LO1. At the end of the scan, the GBT software will
write the corresonding FITS files in these project sub-directories:
* GO
* Antenna
* LO1
However, the PAF system will be responsible for writing it's data, which
includes a large amount of data written to the local AD machines, as
well as 2 small FITS files. Using the 'mkdir' command above, these files
can be written to any directory accesible to the network. Our task will
be to call this command from our manager so that these 2 FITS files are
written to the 'RcvrPAF' and 'FXCorPAF' directories in
/home/gbtdata/project_dir.
It will be the responsibility of the M&C Manager to make sure that these
two directories are created.
4.6 Miscellaneous
* PAF needs nominal entries in the PFM Database
* PAF needs to be added as a new receiver the Scan Coordinator's list.
* No changes needed to measurements database! (since we won't have
Measurements manager in the Scan Coordinator).
* Sessions using the PAF receiver must be scheduable, at least as
Fixed Sessions in the DSS (see
https://safe.nrao.edu/wiki/bin/view/GB/Software/HowToUpdateAntiochReceivers).
For dynamic scheduling, it can be treated like the L band receiver.
* double check:
https://safe.nrao.edu/wiki/bin/view/GB/Knowledge/NewManagerIntegration
5. Example Observing Session
Here's how I would imagine all this stuff would actually work once the
software is released:
* Investigators write Scheduling Blocks (SB) for the PAF project:
o one SB named Setup looks like this:
# Observing script of PAF; first configure
config_paf = """
receiver = Rcvr_PAF
"""
Configure(config_paf)
# now change any parameters from their default values
SetValues('PAF', 'rest_freq', 1.4)
# set the LO1
SetValues('LO1A', 'freq', 1000.0)
*
o another SB named Map calls the commands (beyond the scope of
this MR) to run several scans for making a map with the PAF.
* Some PAF observations get scheduled using the DSS
* Investigators start by investigator starting up Astrid, loading
their project, and submitting SB 'Setup'
* If the Investigator were to have the CLEO Scan Coordinator screen
up, they'd see that the SC now has three managers to coordinate:
PAF, Antenna, LO1
* Possible issue here: no feedback from the PAF system means that at
this point, beyond blatant errors from the Managers (i.e., socket
commands failed), the investigator has no idea about the health of
the system, and whether subsequent scans are possible or not.
* Investigators submit next SB, 'Map'
* CLEO SC screen shows the three managers going into the usual state
changes for running scans: Activating, Committing, Running,
Stopping, Ready, and over and over again for each scan.
* At the end of each scan, the investigator can see their subsequent
data files produced in /home/gbtdata/project_dir and the local AD
machines of the PAF system.
* 'Exceeds Expectations' check on the PEP
6. Deployment Checklist - For sponsor and/or software engineer
It's likely that when we first start testing this receiver on the GBT,
we won't have this new software in the release: thus during test
observations, we'll probably switch to whatever M&C and/or sparrow
branchs we developed on. This is bad because it's more work for me, but
good since it has less of an impact on the existing production system.
Eventually this will make into the release branch - but the implications
to M&C and observing tools should be minimal: we'll have a new receiver
manager that should *not* affect the rest of the system.
Since we are off the hook for data analysis, no affects on GFM, GBTIDL,
etc. need be considered.
This new receiver will appear on the schedule however, so staff should
be educated on it's existence.
If there's any special considerations concerning the hardware to prepare
for observations (such as special instructions for deploying the feed
arm (this is a prime focus receiver) then they should be shared.
Since we this first phase is for investigators only, no special training
should be needed for staff.
7. Test Plan
7.1 Internal Testing - For the software engineer to fill out
* where ever possible, unit tests will be created
* should be able to test the specific sections of the code that
communicate with hardware via sockets separately:
o ensure that socket commands return values show success.
o use socket commands to run scans - ensure scans run successfuly
* Successful Scans:
o Files exist in correct locations (/home/gbtdata/project_dir and
local paf raw files)
o Files have correct format
o FITS file content match expected results:
+ Basic meta data: scan numbers, project ID, etc.
+ Contents match commands given via sockets (where applicable)
- need to flesh this out.
o Raw data on paf machines can be tested via Rick's software:
check for the marker tone burst at the beginning of the scan and
do an integrated FFT on the data values to verify that you see a
passband shape.
* tests of the new Manager in the Simulator via Device Explorer
(incorporates above tests)
* tests using Astrid Scheduling Blocks in the Simulator (also
incorporates above tests)
* Finally testing using the real GBT (without Antenna motion, during
maintenance?)
7.2 Sponsor Testing
Sponsor Testing plan:
* Create Astrid Scheduling Block for PAF project:
o use Configure command to specify PAF
o use SetValues?
</wiki/bin/edit/GB/Software/SetValues?topicparent=GB/Software.ModificationRequest1Q412>
to set any of the parameters (as specified in
requirements) to non-default values.
*
o use Track to start a scan.
* Submit said scheduling block
* At the end of the scan, the appropriately named FITS files should
appear in /home/gbtdata/'project_dir' in the following sub directories:
*
o Antenna
o LO1
o GO
o RcvrPAF?
</wiki/bin/edit/GB/Software/RcvrPAF?topicparent=GB/Software.ModificationRequest1Q412>
o FXCorPAF?
</wiki/bin/edit/GB/Software/FXCorPAF?topicparent=GB/Software.ModificationRequest1Q412>
(this may take more time to be written)
* The FITS files should be 'correct':
o Files exist in correct locations (/home/gbtdata/project_dir and
local paf raw files)
o Files have correct format
o FITS file content match expected results:
+ Basic meta data: scan numbers, project ID, etc.
+ Contents match commands given via sockets (where applicable)
- need to flesh this out.
o Raw data on paf machines can be tested via Rick's software:
check for the marker tone burst at the beginning of the scan and
do an integrated FFT on the data values to verify that you see a
passband shape.
7.3 Integration/Regression Tests
This is not very applicable, since the software changes will be for
investigator use only. The only test is the usual 'have we screwed
anything else up' test.
------------------------------------------------------------------------
Signatures
*APPROVED*: To the best of my knowledge, the requirements section of
this MR is complete and the other sections contain a reasonable plan
forward.I have thought through this request, and believe it to be an
important feature to implement or bug to fix.
*ACCEPTED*: I acknowledge that I have validated the completed code
according to the acceptance tests.
Written DONE - PaulMarganian </wiki/bin/view/Main/PaulMarganian> -
2012-07-06
Checked DONE - JoeBrandt </wiki/bin/view/Main/JoeBrandt> - 2012-07-09
Approved by Sponsor DONE - RickFisher </wiki/bin/view/Main/RickFisher>
- 2012-07-11
Approved by CCC DONE - RichardPrestage
</wiki/bin/view/Main/RichardPrestage> - 2012-07-26
Accepted/Delivered by Sponsor symbol - name - date
*Symbols*:
* Use |%X%| if MR is not complete (will display ALERT!)
* Use |%Y%| if MR is complete (will display DONE)
------------------------------------------------------------------------
CCC Discussion Area
Attachments 5 <#>Attachments 5 <#>
Topic attachments I
</wiki/bin/view/GB/Software/ModificationRequest1Q412?sortcol=0;table=5;up=0#sorted_table>
Attachment
</wiki/bin/view/GB/Software/ModificationRequest1Q412?sortcol=1;table=5;up=0#sorted_table>
Action
</wiki/bin/view/GB/Software/ModificationRequest1Q412?sortcol=2;table=5;up=0#sorted_table>
Size
</wiki/bin/view/GB/Software/ModificationRequest1Q412?sortcol=3;table=5;up=0#sorted_table>
Date
</wiki/bin/view/GB/Software/ModificationRequest1Q412?sortcol=4;table=5;up=0#sorted_table>
Who
</wiki/bin/view/GB/Software/ModificationRequest1Q412?sortcol=5;table=5;up=0#sorted_table>
Comment
</wiki/bin/view/GB/Software/ModificationRequest1Q412?sortcol=6;table=5;up=0#sorted_table>
PAFPhaseOne.jpgjpg PAFPhaseOne.jpg
</wiki/pub/GB/Software/ModificationRequest1Q412/PAFPhaseOne.jpg> manage
</wiki/bin/attach/GB/Software/ModificationRequest1Q412?filename=PAFPhaseOne.jpg;revInfo=1>
30.4 K 2012-06-29 - 16:29 PaulMarganian
</wiki/bin/view/Main/PaulMarganian>
PAFPhaseOne.vsdvsd PAFPhaseOne.vsd
</wiki/pub/GB/Software/ModificationRequest1Q412/PAFPhaseOne.vsd> manage
</wiki/bin/attach/GB/Software/ModificationRequest1Q412?filename=PAFPhaseOne.vsd;revInfo=1>
75.5 K 2012-06-29 - 16:29 PaulMarganian
</wiki/bin/view/Main/PaulMarganian>
PAF_on_the_GBT.docxdocx PAF_on_the_GBT.docx
</wiki/pub/GB/Software/ModificationRequest1Q412/PAF_on_the_GBT.docx>
manage
</wiki/bin/attach/GB/Software/ModificationRequest1Q412?filename=PAF_on_the_GBT.docx;revInfo=1>
98.4 K 2012-06-28 - 16:43 PaulMarganian
</wiki/bin/view/Main/PaulMarganian>
paf_blk_diag.pdfpdf paf_blk_diag.pdf
</wiki/pub/GB/Software/ModificationRequest1Q412/paf_blk_diag.pdf>
manage
</wiki/bin/attach/GB/Software/ModificationRequest1Q412?filename=paf_blk_diag.pdf;revInfo=1>
3.6 K 2012-06-28 - 16:43 PaulMarganian
</wiki/bin/view/Main/PaulMarganian>
pf_blk_diag1.jpgjpg pf_blk_diag1.jpg
</wiki/pub/GB/Software/ModificationRequest1Q412/pf_blk_diag1.jpg>
manage
</wiki/bin/attach/GB/Software/ModificationRequest1Q412?filename=pf_blk_diag1.jpg;revInfo=1>
27.8 K 2012-06-28 - 16:47 PaulMarganian
</wiki/bin/view/Main/PaulMarganian>
Edit
<https://safe.nrao.edu/wiki/bin/edit/GB/Software/ModificationRequest1Q412?t=1352299975> | Attach
</wiki/bin/attach/GB/Software/ModificationRequest1Q412> | Print version
</wiki/bin/view/GB/Software/ModificationRequest1Q412?cover=print;> | History
</wiki/bin/oops/GB/Software/ModificationRequest1Q412?template=oopshistory>:
r17 <
</wiki/bin/compare/GB/Software/ModificationRequest1Q412?rev1=16;rev2=17> r16
</wiki/bin/view/GB/Software/ModificationRequest1Q412?rev=16> <
</wiki/bin/compare/GB/Software/ModificationRequest1Q412?rev1=15;rev2=16> r15
</wiki/bin/view/GB/Software/ModificationRequest1Q412?rev=15> <
</wiki/bin/compare/GB/Software/ModificationRequest1Q412?rev1=14;rev2=15> r14
</wiki/bin/view/GB/Software/ModificationRequest1Q412?rev=14> | Backlinks
</wiki/bin/view/GB/Software/ModificationRequest1Q412?template=backlinksweb> | View
wiki text
</wiki/bin/view/GB/Software/ModificationRequest1Q412?raw=on> | Edit wiki
text
<https://safe.nrao.edu/wiki/bin/edit/GB/Software/ModificationRequest1Q412?t=1352299975;nowysiwyg=1> | More
topic actions
</wiki/bin/view/GB/Software/ModificationRequest1Q412?template=more&maxrev=17&currrev=17>
Topic revision: 2012-11-02, PaulMarganian
</wiki/bin/view/Main/PaulMarganian>
GB/Software <https://safe.nrao.edu/wiki/bin/view/GB/Software/WebHome>
* Log In
</wiki/bin/login/GB/Software/ModificationRequest1Q412?foswiki_origin=GET%2cview%2c/wiki/bin/view/GB/Software/ModificationRequest1Q412>
or Register </wiki/bin/view/System/UserRegistration>
*
*
*
------------------------------------------------------------------------
* *home GB/Software Web </wiki/bin/view/GB/Software/WebHome>*
* newtopic Create New Topic
</wiki/bin/view/GB/Software/WebCreateNewTopic?parent=ModificationRequest1Q412>
* index Index </wiki/bin/view/GB/Software/WebTopicList>
* searchtopic Search </wiki/bin/view/GB/Software/WebSearch>
* changes Changes </wiki/bin/view/GB/Software/WebChanges>
* notify Notifications </wiki/bin/view/GB/Software/WebNotify>
* statistics Statistics </wiki/bin/view/GB/Software/WebStatistics>
* wrench Preferences </wiki/bin/view/GB/Software/WebPreferences>
------------------------------------------------------------------------
* *Webs*
house - NRAO Public Wiki
* Main </wiki/bin/view/Main/WebHome>
*
ALMA </wiki/bin/view/ALMA/WebHome>
o NAASC </wiki/bin/view/ALMA/NAASC/WebHome>
o SCIIPT </wiki/bin/view/ALMA/SCIIPT/WebHome>
* CDL </wiki/bin/view/CDL/WebHome>
* CICADA </wiki/bin/view/CICADA/WebHome>
*
Ccs </wiki/bin/view/Ccs/WebHome>
o Littlethings </wiki/bin/view/Ccs/Littlethings/WebHome>
* Cville </wiki/bin/view/Cville/WebHome>
* DSAA </wiki/bin/view/DSAA/WebHome>
* EVLA </wiki/bin/view/EVLA/WebHome>
* FASR </wiki/bin/view/FASR/WebHome>
*
GB </wiki/bin/view/GB/WebHome>
o Computing </wiki/bin/view/GB/Computing/WebHome>
o Data </wiki/bin/view/GB/Data/WebHome>
o Dynamic </wiki/bin/view/GB/Dynamic/WebHome>
o Electronics </wiki/bin/view/GB/Electronics/WebHome>
o Gbtpipeline </wiki/bin/view/GB/Gbtpipeline/WebHome>
o Knowledge </wiki/bin/view/GB/Knowledge/WebHome>
o Mechanical </wiki/bin/view/GB/Mechanical/WebHome>
o Observing </wiki/bin/view/GB/Observing/WebHome>
o Obsreports </wiki/bin/view/GB/Obsreports/WebHome>
o Operate </wiki/bin/view/GB/Operate/WebHome>
o
PTCS </wiki/bin/view/GB/PTCS/WebHome>
+ OOF </wiki/bin/view/GB/PTCS/OOF/WebHome>
+
ServoImprovementsHome
</wiki/bin/view/GB/PTCS/ServoImprovementsHome/WebHome>
# ServoSiteAcceptTestProcs
</wiki/bin/view/GB/PTCS/ServoImprovementsHome/ServoSiteAcceptTestProcs/WebHome>
o Pennarray </wiki/bin/view/GB/Pennarray/WebHome>
o Projects </wiki/bin/view/GB/Projects/WebHome>
o Recreation </wiki/bin/view/GB/Recreation/WebHome>
o Scicenter </wiki/bin/view/GB/Scicenter/WebHome>
o Software </wiki/bin/view/GB/Software/WebHome>
o TACTool </wiki/bin/view/GB/TACTool/WebHome>
* HPC </wiki/bin/view/HPC/WebHome>
* Kbandfpa </wiki/bin/view/Kbandfpa/WebHome>
* Library </wiki/bin/view/Library/WebHome>
* Metrics </wiki/bin/view/Metrics/WebHome>
*
NM </wiki/bin/view/NM/WebHome>
o Computing </wiki/bin/view/NM/Computing/WebHome>
o Electronics </wiki/bin/view/NM/Electronics/WebHome>
* OSAA </wiki/bin/view/OSAA/WebHome>
* OSX </wiki/bin/view/OSX/WebHome>
* Sandbox </wiki/bin/view/Sandbox/WebHome>
*
Software </wiki/bin/view/Software/WebHome>
o Algorithms </wiki/bin/view/Software/Algorithms/WebHome>
* Splat </wiki/bin/view/Splat/WebHome>
* System </wiki/bin/view/System/WebHome>
* VLBA </wiki/bin/view/VLBA/WebHome>
the NRAO Public Wiki <https://safe.nrao.edu/wiki/bin/view/Main/WebHome>
*
*
This site is powered by Foswiki <http://foswiki.org/>Copyright © 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
<mailto:webmaster@nrao.edu?subject=NRAO Public
Wiki%20Feedback%20on%20GB/Software.ModificationRequest1Q412>