svn commit -m 'I made some changes to summarizeparproj and added comments to readparfits'

svn commit -m 'BSM: I made some changes to summarizeparproj and added comments to readparfits'

The changes you made will be committed to whatever version you checked out initially.

The changes you made will be committed to whatever version you checked out initially. Putting your name is helpful because the repository is through a shared account (penarray) it will otherwise be hard to figure out in retrospect what happened if we get confused.

Take a snapshot of the code: here tagged "mustang-excellent-version"

Take a snapshot of the code: ie make a "tagged version", here named "mustang-excellent-version"

Description of What the Pipeline Does

Is at IdlPipelineDescription

There is a subdirectory of the main IDL code directory called "reg" in which I keep scripts demonstrating basic operations on MUSTANG data: the main scripts are called demo-map.pro (not demo-maps.pro, which is for DCR and CCB data), which shows how to analyze on-telescope data, and demo-lab.pro, which demonstrates laboratory type operations (deriving bias curves, analyzing squid feedback ramps, calibrating to picowatts, etc). I also use these, in cut-and-paste fashion, to verify that I've not broken the code before committing major revisions. An example data reduction session follows.

svn log --stop-at-copy

svn log --stop-on-copy

Quick and dirty merge: suppose you want to merge from branches/mydev to the trunk, and that you keep working directories in your home area.

# assume everything in the branch has already been committed
cd ~/branchesworkingdir
# get range of revision numbers--
svn log --stop-at-copy
cd ~/
svn co svn+ssh://myurl/trunk ./trunkworkingcopy
cd trunkworkingcopy
svn merge -r revStart:revEnd svn+ssh://myurl/branches/mydev
# see what was modified--
svn status
# look at them...
svn diff modifiedfile1
# etc
# then test the code in trunkworking copy (be sure your path points at the working directory --
#  script mustangidltest can be easily modified to do that)
# when happy--
svn commit

%META:TOPICINFO{author="BrianMason" date="1204492440" format="1.0" version="1.1"}% %META:TOPICPARENT{name="WebHome"}%

MUSTANG IDL Data Analysis Code

• MUSTANG IDL Data Analysis Code
  • Public Version
  • Basic Operations
  • Developers' Access

Public Version

A tested, public version of the code is kept in ~bmason/mustangidlbin/ This is the code recommended for online use (observing)

The shell script ~bmason/mustsangPub/mustangidl will correctly configure your IDL path to point to this area. The shell script also has provisions to add your own area to the path in addition, and to use the IDLDE instead of the command-line IDL. You can safely copy this script to another place, edit it per the instructions in the comments, and use it.

Basic Operations

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; Example MUSTANG data analysis script
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; set up pipeline variables and indexscans
;  -the pardatapath option is only needed if the data aren't in /home/gbtdata/
;  -parwritefiles=1 (defaults to zero) causes text file output to be
;    generated (for instance, the project summary)
setparpipeopts,parproj='TPAR_19',parwritefiles=1
indexscans,si

; summarizeproject -- exclude a few scans which perhaps
;   crash the code. (Useful to exclude, say, aborted
;   scans and the current, not-fully-written scan)
summarizeparproj,myproj,excludescans=[1,12]
; structure myproj can now be used
;  via showparproj to see what you've done. as in:
showparproj,myproj
; which is much faster

; determine weights, crmask, and gains from a cal an
;  a blank scan
; results are passed back througn gain,crmask,wtarr
;  qc and qw are structures with the actual data that was read in
; The gain array is in units of COUNTS per JANSKY which should
;   be in the 25-50 range. pass optional argument janskys=0
;   to get the gain in counts per cal.
docalib,calscan=96,blankscan=97,gain=gain,crmask=crmask,wtarr=wtarr,qc=qc,qw=qw

best_focus,[98,99],gain=gain,crmask=crmask,wtarr=wtarr,results=results
best_focus,[100],gain=gain,crmask=crmask,wtarr=wtarr,results=results,/append
; this time we think there's a problem with the automatically
; determined timestamp correction so we force it to zero--
best_focus,[101],gain=gain,crmask=crmask,wtarr=wtarr,results=results,/append,tfix=0
; although now, it's almost as fast to simply reprocess the original
;  scans as you go...

; make a map
;  this does subcommon:
skyimage2=multimakemap([99],gain=gain,crmask=crmask,wtarr=wtarr)
; this does offsrcpolyfit plus the 1.4 Hz common-mode filter for the
; pulse tube--
skyimage2b=multimakemap([99],gain=gain,crmask=crmask,wtarr=wtarr,/polyfit,/ptfilter)
; If you can stand not having ra/dec, elxel=1 makes them run much faster...
;
; replot the first map
loadct,3
plotmap,skyimage2
; plot the coverage map
plotmap,skyimage2,/cover

; if we want to look at some cal data in the physical
;   array face orientation, do this (note by default
;   this uses the current best determination of
;   the array face offsets indicated by the global
;   variable !parfaceofffile
plotface,qc,/vstime,xrange=[2,7],/bycol,/crlab,crmask=crmask

Developers' Access

The code is available through Subversion. Outside of the observatory access must be through an ssh tunnel. Some examples of basic operations:

Check out the current code

svn checkout  svn+ssh://penarray@ssh.gb.nrao.edu/home/scratch/penarray/idlutils-svn/trunk ./myLocalWorkingDir

Check out a specific tagged version

svn checkout  svn+ssh://penarray@ssh.gb.nrao.edu/home/scratch/penarray/idltools-svn/tags/mustang-feb-28-2008 ./myCodeDistribDir

Committing the changes you made

svn commit  -m 'I made some changes to summarizeparproj and added comments to readparfits'

List the available tagged versions of the code

svn list svn+ssh://penarray@ssh.gb.nrao.edu/home/scratch/penarray/idlutils-svn/tags

Make a branch for independent development:

svn copy svn+ssh://penarray@ssh.gb.nrao.edu/home/scratch/penarray/idlutils-svn/trunk svn+ssh://penarray@ssh.gb.nrao.edu/home/scratch/penarray/idlutils-svn/branches/myindependentbranch

Take a snapshot of the code: here tagged "mustang-excellent-version"

svn copy svn+ssh://penarray@ssh.gb.nrao.edu/home/scratch/penarray/idlutils-svn/trunk svn+ssh://penarray@ssh.gb.nrao.edu/home/scratch/penarray/idlutils-svn/tags/mustang-excellent-version

Schedule a file to be added to the repository upon the next commit:

svn add myfile.pro

Update your working copy-- get the latest things that have been committed to the branch you initially checked out

svn update

When you perform most of these operations a password will be requested. This is penarray's standard unix password.

Good Practices

• idltools-svn/trunk contains the "main" line of development
• use subdirectories of idltools-svn/branches contain separate, parallel branches of development if you'll be doing a lot of changes
• use the first 100 lines or so of reg/demo-maps to do a final test of the code before comitting to the trunk
• make periodic snapshots (tagged copies) of the code in subdirectories of idltools-svn/tags
• after merging back to the trunk, run the demo-map tests and fix any problems that arise.
• comment the code; add more general descriptions to DevNotes?; and use -m to comment commits.

This may all be over the top. With the small group we have, we may not need branches, merges, and tags -- we could all just check out from, and commit to, the trunk. We'll see how it goes!

The Subversion Red Book is the authoritative reference.

-- BrianMason - 02 Mar 2008