Open-source software for geodetic imaging: ROI_PAC for InSAR and pixel tracking

Open-source software for geodetic imaging: ROI_PAC for InSAR and pixel tracking Authors: Matthew E. Pritchard; and contributors to the ROI_PAC wiki Version: 0.4 May, 2014 Deformation Discovery: Interferogram from southern Peru showing ground displacement from at least 3 different origins within 50 km. The deformation in the upper left was expected as this interferogram spans an earthquake swarm that occurred in October, 2005. However, this data show that the locations from some global earthquake catalogs are in error by 10 km or more. The other two areas of deformation are newly discovered but based on their characteristics in a volcanic region (center) and near a Lake (lower right), volcanic and groundwater related sources of deformation are suggested. The dates of the two images used are 17 June 2006 and 4 December 2004 are from the Envisat spacecraft of the European Space Agency. 1

Overview of Contents Section 0. Acknowledgements Section I. Introduction Section II. Getting started: Data & software Raw data format Available software for InSAR and pixel tracking Appendix 0: Some basic LINUX commands Appendix 1: Getting and installing ROI_PAC Appendix 2: ROI_PAC file types and file formats Appendix 3: ROI_PAC processing flow: Script-by-Script Appendix 4: User defined options for ROI_PAC processing Appendix 5: Which scripts created each file generated by ROI_PAC? Appendix 6: What is the information in the RSC files? Appendix 7: Access to data and special processing considerations for each satellite Appendix 8: Viewing ROI_PAC output files and moving them to other programs Appendix 9: ROI_PAC Troubleshooting Appendix 10: What ROI_PAC can t do (yet) Appendix 11: Annotated bibliography of useful books and websites References 2

Section 0. Acknowledgements The impetus for this textbook was a realization that although there are many useful review papers and a few textbooks about InSAR and pixel tracking (e.g., Hansen, 2001; Kampes, 2006; Simons & Rosen, 2007; Massonnett & Feigl, 1998; Burgmann et al., 2000; Rosen et al., 2000; Chapter co-authored by Zhong Lu in Dzurisin, 2007; Feretti, 2014) there is no existing textbook on the rapidly developing field of imaging geodesy that explicitly helped new users get started using real data and software. Demand for such a textbook is high from attendees at the UNAVCO short courses and others. So, in 2009, Matt Pritchard proposed to write such a document as an online, free textbook as part of the education plan in a National Science Foundation CAREER that was funded in 2010. The focus here is on practical concerns of using the software, and we refer the reader to the literature for theoretical developments. In particular, a chapter from the Ph.D. thesis of Sean Buckley (a modified version is available online: http://www.geo.cornell.edu/eas/peopleplaces/faculty/matt/roi_pac_doc.pdf) documents some of the equations used in the software described in this text. Further corrections and additions to the textbook are planned at least until the end of the grant in 2016, so please send any suggestions or comments to Pritchard@cornell.edu. The materials in this book have been merged from many sources and many authors web pages, scientific papers and presentations, theses, classroom lectures and short courses, one-onone training and so on. We thank all of the students and postdocs over the years who have commented on these documents and presentations and contributed to their development. We especially thank the approximately 170 attendees of the annual 2.5-3 day UNAVCO short courses from 2008-2014 entitled InSAR: An introduction to Processing and Applications for Geoscientists (with an optional module for pixel tracking) that were taught by Eric Fielding (JPL, 2008-2012), Paul Rosen (JPL, 2008-2012), Yuri Fialko (UCSD, 2008); Matt Pritchard (Cornell, 2009-2012), Scott Baker (UNAVCO 2012-2013), Walter Szeglia (Central Washington University, 2012-2013), and Piyush Agram (JPL, 2013) we further thank the UNAVCO staff for helping to organize these courses. The ROI_PAC software (Rosen et al., 2004) that is discussed extensively in this book was developed over several decades by researchers at the Jet Propulsion Laboratory (JPL) and the California Institute of Technology (Caltech) in Pasadena, CA. Some parts of ROI_PAC date back to the early 1980's and the pioneering spacebourne InSAR work done by Dick Goldstein, Howard Zebker and others (Goldstein et al, 1986). During the 1990's, Gilles Peltzer and colleagues started to put together the programs into a set of scripts. Through the collective efforts of the following people, ROI_PAC was created: Paul Rosen (JPL), Scott Hensley (JPL), Gilles Peltzer (JPL/UCLA), Francois Rogez (JPL), Frederic Crampe (JPL/UCLA), Eric Fielding (JPL), Mark Simons (Caltech), Rowena Lohman (Caltech undergrad/grad student, now at Cornell), and Matt Pritchard (Caltech grad student now at Cornell). 3

Section I. Introduction For centuries, measurement of the shape of the Earth (called the science of geodesy) was necessarily time consuming. Even with new technologies like the Global Positioning System (GPS), vast portions of the Earth remain infrequently monitored for movement. Over the past 20 years, a new form of geodesy has rapidly developed whereby satellite images can be compared to infer movements of the Earth's surface. Called imaging geodesy, the synoptic aircraft or satellite views allow large regions to be surveyed densely without any human setting foot in the area. Imaging geodesy encompasses several different types of methods including Interferometric Synthetic Aperture Radar (InSAR, e.g., Rosen et al., 2000) as well as the automated comparison of SAR and optical images via the techniques of pixel or feature tracking (e.g, Leprince et al., 2007). InSAR can image sub-centimeter deformation of the Earth's surface every 20 meters over areas spanning hundreds to thousands of kilometers. InSAR has allowed vast areas of the Earth's surface to be monitored frequently for deformation for the first time and led to discoveries in a variety of fields (including signals caused by earthquakes, volcanoes, landslides, glaciers, groundwater, and human-induced ground deformation). Pixel tracking is a very complementary tool to InSAR-- although the sensitivity to deformation is less (decimeter instead of subcentimeter in a given image pair) and the horizontal spacing is coarser, it can be applied to both radar and optical images and often works when InSAR does not for example, in areas that have large displacements or changes to the radar scattering properties of the ground. Section II. Getting started with InSAR and pixel tracking: Data & software Radar is a commonly used word, but it is actually an acronym for RAdio Detection And Ranging and involves the active transmission and reception of microwave energy to measure distance. The waves in the radar portion of the electromagnetic spectrum have frequencies from 0.3-30 GHz or wavelengths of 1 cm 1 m. Different portions of this spectrum were divided into code names during World War II and these codes are still widely used. The most commonly used codes by satellite radars are X-band (~2.5-3.75 cm wavelength), C-band (3.75-7.5 cm), and L-band (15-30 cm), although the S band (7.5-15 cm) was used on NASA Magellan mission to Venus, the Cassini mission to Saturn uses Ku band (1.67-2.5 cm), and P-band (> 1 m) is sometimes used on airplane imaging radar systems. For reference, ground-penetrating-radars are typically in the UHF to VHF bands of.05-1 GHz (30 cm to 6 m), weather radars can be in the K, X, C, and S bands, air traffic control radars can include L, S, and X bands and cell phones, Wi- Fi, television, and Bluetooth typically are in the UHF band that overlaps mostly with the P but partly with the L band. Radars have a wide variety of uses, but we will be considering imaging radars that are able to distinguish fine details in two-dimensional arrays that constitute images of the ground. Specifically, we use Synthetic Aperture Radar (SAR), a common imaging technique used on a moving platforms (like an air- or spacecraft) to produce high resolution images in the along-track direction. SAR Raw Data Format The format of raw SAR data varies depending on the satellite and a compilation of documentation of several different formats is available here: http://aws.roipac.org/cgibin/moin.cgi/raw_formats SAR raw data is often delivered in the Committee on Earth 4

Observation Satellites (CEOS) format. The CEOS-format SAR raw data nominally consists of a Volume Directory File (ASCII), SAR Leader File (mixed ASCII and Binary), Raw Data File (Binary), and a Null Volume File (ASCII). The Volume Directory File describes the arrangement of the data on the storage media (tape, CD, file directory, etc.). The SAR Leader File provides pertinent information about the specific SAR data set: Raw Data File size, spacecraft height and velocity, scene center latitude, longitude and time of acquisition, etc. The Raw Data File contains a header record plus the SAR raw data nominally stored as one data line per record. Each value in the header contains useful information about the parameters of the data collected (the satellite clock time, line number, etc.) that are documented by the space agencies (http://aws.roipac.org/cgi-bin/moin.cgi/raw_formats). Each record line consists of a prefix (header in the case of ERS, this is 412 bytes), raw data (see next paragraph), and a suffix (not always used). The binary SAR raw data (excluding the header and suffix on each line) is commonly stored in two formats as a complex number in I/Q (in-phase (real) and quadrature (imaginary) components) or offset video (real numbers). We focus on the I/Q format, as it is the most common for the satellites we discuss here (the offset video was used for SEASAT). The choice of data formats is governed by how the radar signal returned to the satellite from the ground (the echo) is converted from an analog to digital. The I/Q format uses a complex converter while offset video requires a more complicated converter to save as real numbers but the total number of data points in each format is the same. Each format has different advantages and requires different algorithms to process. For each return sample, the received voltage is recorded as an integer byte values -- each byte is made up of 8 bits and each bit has a value of 0 or 1. For example, ERS SAR raw data is 5-bit quantized, i.e., the voltage is recorded as one of 32 values (2 5 ) -- between 0 and 31, and the JERS-1 data are quantized to 3 bits (or between 0 and 7). Thus, JERS and ERS data are significantly smaller than the equivalent binary files composed of floating point numbers that are typically made up of 4 bytes each (each byte is 8 bits), and the data can be easily read on all types of computers (no matter if they are big endian or little endian). In order that negative voltages can be recorded, a bias is added to all returned voltages. For ERS, this bias is about 15.5 (small deviations from this nominal value can be determined from the raw data and are typically calculated by the satellite downlink facility and included in the leaderfile). To convert the raw data number (dn) to a voltage (V), use the expression: V = A * (dn-15.5) where A is a scaling constant depending on the gain of the radar receiver and analog to digital quantizer. Since the data is quantized directly as complex numbers, each returned sample is recorded as a real and imaginary component for the I/Q format thus the signal from a given sample is complex(dn 2*n-1-15.5,dn 2*n -15.5) where n is the column number. The raw data file can be viewed using the program mdx (Appendix 8) using the following command: Mdx i1 FILENAME LINELENGTH (show example figure). Available software Pixel tracking: 5

Pixel tracking with ROI_PAC: A set of python scripts (download here: http://www.geo.cornell.edu/eas/gstudent/akm/pixeltrack.tar) have been released that use ROI_PAC to generate dense sub-pixel offsets of optical or SAR using the method of normalized cross correlation (NCC), which computes the offsets in the spatial domain (like the program IMCORR). Cosi-Corr (Leprince et al., 2007) An open-source program to generate sub-pixel offsets is called COSI-CORR (available at http://www.tectonics.caltech.edu/slip_history/spot_coseis/index.html) that generates subpixel offsets of optical images that can use either NCC or a different algorithm called the Fourier Shift Theorem. COSI-CORR requires the use of the GIS package ENVI and the commercial software package IDL, which are usually available for $2000-$3000 to academic users. IMCORR (Scambos et al., 1992), Open source software (available at http://nsidc.org/data/velmap/imcorr.html) that uses NCC to generate sub-pixel offsets between optical images. InSAR software: ROI_PAC: The Repeat Orbit Interferometry PACkage developed at JPL and Caltech, is a collection of fortran and C programs bound together with perl scripts to perform certain routine but important tasks in synthetic aperture radar (SAR) repeat orbit interferometry. Specifically, the individual programs perform everything from raw data conditioning, SAR image processing, interferogram formation, correlation estimation, phase unwrapping, baseline determination, estimation of topography, removal of topography from a deformation interferogram, and geocoding. The perl scripts control certain prescribed ways of combining these programs to specifically create a geocoded deformation phase or topographic phase image from two satellite radar images and a digital elevation model, or create a deformation phase image from three radar images without a digital elevation model. The perl scripts allow considerable control over every step of the processing, such that individual programs or combinations of programs can be manipulated to produce a more favourable output without direct interaction with the program itself. ROI_PAC does not perform well with airborne sensors because it does not include motion compensation. The software is described in Rosen et al., (2004) and this is the article that should be cited when using the software. The software package is the most widely used for InSAR processing in the peer-reviewed scientific literature (over 3000 unique downloads since 2003 and 150 peer-reviewed publications, roipac.org/bibliolist) ISCE: InSAR Scientific Computing Environment is a new Stanford/Caltech/JPL software package that builds on some of the FORTRAN and C programs in ROI_PAC but is faster, more accurate, and provides better geolocation (Gurrola et al., 2010; Rosen et al., 2009; Zebker et al., 2010). For example, it uses a motion-compensated geodetic coordinate system (used to process SRTM and UAVSAR data, for example) instead of the range/doppler coordinate system of ROI_PAC. Using this motion-compensated 6

coordinate system from the start facilitates time series analysis because co-registration of images before they can be combined is not required (as in ROI_PAC). Another difference is that ISCE uses python instead of Perl Scripts. Licensing for ISCE is available to WInSAR members through UNAVCO. GMTSAR: http://topex.ucsd.edu/gmtsar/ Open source InSAR processing software based on the open source Generic Mapping Tool (GMT) package (Sandwell et al., 2011) DORIS (http://doris.tudelft.nl/) is another open source suite of InSAR processing software that is being integrated in the NEST (Next ESA SAR Toolbox) software packaged (http://nest.array.ca/web/nest). Training in the use of the NEST software is available: (http://earth.eo.esa.int/workshops/fringe2011/index.php?page=164&type=s) Open source software to create InSAR time series using multiple methods (Agram et al., 2013): GIANT (http://earthdef.caltech.edu/projects/giant/wiki) Open source software for Atmospheric Phase Screen removal (Jolivet et al., 2011) Pyaps (http://earthdef.caltech.edu/projects/pyaps/wiki/main) Other notable InSAR processing software that is commercially available includes: GAMMA http://www.gamma-rs.ch/ Nigel Press Associates (NPA) (http://www.cgg.com/default.aspx?cid=5837); DIAPASON (http://www.altamira-information.com/html/1-18215-insar-software-- Training.php); 7

Appendix 0: Some basic LINUX commands ROI_PAC requires users to use UNIX or LINUX and interact with their computer via the command line. For many people, use of the command line requires a period of adjustment usually lasting a day or two. The key point to remember is that LINUX is based on a directory structure so you need to constantly be aware of what directory you are currently in. There are many good resources on the web that provide a quick introduction to LINUX -- for example: http://www.math.utah.edu/lab/unix/unix-tutorial.html, http://linuxreviews.org/beginner/, and http://freeengineer.org/learnunixin10minutes.html. Here we provide a very short list of some essential commands. The Top 16 Most Useful LINUX commands you will use everyday 1) ls List the files and subdirectories ls -alf will list the files and directories with additional useful information (size, date of last modification, and who has permission to read/write) For example, here is some example output: -rw-r--r-- 1 matt staff 240758 Mar 23 2009 myfile.pdf drwxr-xr-x 6 matt staff 204 Jan 11 2011 Stephen/ An important trick in LINUX is the use of wildcards. If I wanted to display all the interferogram files, I would type ls *.int On many computers, different types of files show up as different colors. Directories are one color, files that you can execute are another, files that are linked (see below) another, etc. 2) man Display the manual pages for any command. For example, typing man ls would allow you to see all of the options you can type with the ls command including ls -alf 3) cd change directory cd by itself takes you to your home directory (usually /home/yourname) cd.. moves you one directory up cd./name moves you down into directory NAME cd /FULL/PATH moves you to the specific directory /FULL/PATH that may neither be directly up or down from your current location 4) cp Will copy a file a new version will be made and the original will be saved 8

The usual syntax is cp OLDFILE NEWFILE where OLDFILE is the existing file and NEWFILE is the name of the file you wish to create. You can create the NEWFILE in a different directory if you include the full path 5) mv Will move a file. The original version will not be saved. Useful when you do not want to have two copies of a large file. 6) ln -s Sometimes a file is so big that you do not want to move the whole thing, but instead want to link a large file from one directory to another. For example, ROI_PAC uses this command with the large single look complex files. The syntax is ln -s ORIGINAL_FILE /NEW/FILE/DESTINATION 7) rm Will remove or delete a file. USE WITH CAUTION Useful flags are rm f to force without having to be asked permission and rm r to remove all files and subdirectories in a directory 8) pwd Will show you the path of the current directory you are in. It stands for print working directory. 9) Edit text files. There are many ways to do this depending on what computer you are on. If you are on a Mac, you can use the program TextEdit. Many machines have a program called emacs which allows you to interact with the text file in a familiar menu based manner (like Word). If you want to go old school you can learn how to edit using a program called vi that works on all platforms. A web search for vi will reveal all the commands you need to use this program. 10) more Prints the contents of a text file to screen. Use the spacebar to scroll forward and type q to exit. 11) chmod Allows you to change the permissions on a file (to give others the ability to read, write or execute the file). 12) source ROI_PAC sets up a list of file name shortcuts in a file called SAR_CONFIG. Any time you change this file you need to type source SAR_CONFIG to make the changes active. Every time you log in, your computer runs a program called.bash_profile or something similar if you are using a shell other than bash. You can set your computer to run this command automatically for you every time you log in by typing this command in your.bash_profile file: source /PATH/SAR_CONFIG where PATH is the directory where the SAR_CONFIG file is located. 13) df -k Displays the amount of disk space currently being used (in terms of bytes and %) and how much is available. Important so you don t overfill the disk. 14) du -ks./* This command allows you to see the size of the all the files within a set of subdirectories. The ls command will show you the size of individual files but will not sum the 9

contents of an entire directory. This command is useful to see which directories are taking up the most disk space. 15) grep Extremely useful command for extracting information from text files by doing a search. For example, if I want to find the pixel size of a certain file, I would type grep PIXEL_SIZE FILENAME where it would search for the phrase PIXEL_SIZE in all the files named FILENAME 16) mkdir NAME Makes a new subdirectory with NAME 10

Appendix 1: Getting and installing ROI_PAC Getting ROI_PAC ROI_pac is copyrighted software that requires a license. Licenses are available at no charge for non-commercial use from Open Channel Foundation (http://www.openchannelfoundation.org/projects/roi_pac) Installation The new release (v. 3.0.1) has a very different installation system compared to releases before v. 3.0. The easiest way to build it is explained in the ROI_PAC_3_0_1/ROI_PAC/AAREADME_BUILD_ROIPAC file. 1. Expand Archive Uncompress and untar the archived file. (Command line input is in red) % tar -xzf ROI_PAC_3_0_1.tgz 2. Read the documentation Read through the text file ROI_PAC_3_0_1/AAREADME and the additional documentation found in ROI_PAC_3_0_1/ROI_PAC/DOC. The instructions for installing the software and running the scripts are described in ROI_PAC_3_0_1/ROI_PAC/DOC/Setup and ROI_PAC_3_0_1/ROI_PAC/AAREADME_BUILD_ROIPAC. The most important steps are summarized below. % cd ROI_PAC_3_0_1 % less AAREADME 3. Compile Executables Follow the instructions in the file ROI_PAC_3_0_1/ROI_PAC/AAREADME_BUILD_ROIPAC. Copy and paste each command individually into a shell. These commands will build and test the software package for multiple compilers. If problems are encountered, refer to the bottom of AAREADME_BUILD_ROIPAC for platform specific issues or look through prior posts on the forum (http://www.openchannelfoundation.org/forum/forum.php?forum_id=99) at Open Channel Foundation. To see what shell you are using, type echo $SHELL on the command line. % cd ROI_PAC_3_0_1/ROI_PAC % less AAREADME_BUILD_ROIPAC % which ifort g95 f90 pgf95 f95 xlf gfortran cc gcc icc % touch aclocal.m4 Makefile.in configure %./contrib/install-fftw.sh CC=cc % export FFTW_LIB_DIR=/software/ROI_PAC_3_0_1/ROI_PAC/NetInst/fftw-071005-1457/lib % export FFTW_INC_DIR=/software/ROI_PAC_3_0_1/ROI_PAC/NetInst/fftw-071005-1457/include %./contrib/multibuild.sh etc. 11

When testing the build, you will need to gunzip the provided test data set prior to running the script multitest.sh. % ls ROI_PAC_3_0_1 ROI_PAC_3_0_1.tgz roi_pac_testdir.tar.gz % gunzip roi_pac_testdir.tar.gz % cd ROI_PAC_3_0_1/ROI_PAC/test-runs %../contrib/multitest.sh /full_path/roi_pac_testdir.tar /full_path/roi_pac_3_0_1/roi_pac/multibuild-071005-1506/installs/share/roi_pac /full_path/roi_pac_3_0_1/roi_pac/multibuild-071005-1506/installs/defaults/bin /full_path/roi_pac_3_0_1/roi_pac/multibuild-071005-1506/installs/gfortran/bin Each test run should take ~40 minutes depending on your computer. If the test fails while processing the DEM contained in roi_pac_testdir.tar, you may have to manually swap this DEM file with one that has the proper byte order for your machine (i.e., little-endian versus big-endian, http://en.wikipedia.org/wiki/little_endian#endianness_and_hardware see TEST_DIR/AAREADME). If the test is successful, the finished product is the file geo_930110-950523.unw which should be buried within the directory structure (check in testruns/defaults/test_dir/int_930110_950523). You can view the image file using the program mdx, if you already have it installed. Otherwise, you can try to view the file with a different program that can display binary image files (i.e., Matlab, ENVI, ERmapper). The file is composed of floating point values in a band-interleave format, i.e. alternating lines of magnitude and phase. The size of the file should be just under 10 MB. The meta-data for the file can be found in geo_930110-950523.unw.rsc. If you have progressed this far, congratulations! You have a working version of ROI_PAC. 4. Install Executables Make a new directory called INT_BIN where you will deposit the final executables. % mkdir ROI_PAC_3_0_1/ROI_PAC/INT_BIN You can copy the set of executables from the multi-build operation. Choose one of the successful builds found in ROI_PAC_3_0_1/ROI_PAC/multibuild*/installs. % cd ROI_PAC_3_0_1/ROI_PAC/multibuild*/installs/defaults/bin % cp * ROI_PAC_3_0_1/ROI_PAC/INT_BIN/. NOTE: If you plan to use ODR orbit files, then the getorb (http://www.deos.tudelft.nl/ers/precorbs/tools/getorb_pack.shtml) executable (installed separately) must be located in INT_BIN. You can copy the executable into this directory or make a symbolic link. NOTE: After finishing this step, please check the Patches (http://aws.roipac.org/cgibin/moin.cgi/patches) page to review/install any version specific corrections. 12

5. Configure SAR_CONFIG The shell script SAR_CONFIG controls the location of the code and scripts. Once this is set properly the tools of ROI_PAC should be available to the user. SAR_CONFIG describes how to establishes required environment variables pointing to the programs and perl scripts that ROI_PAC uses, as well as the location of orbit data and other ancillary data. ROI_PAC will absolutely not work if these are not set properly. Create your personal copy with the settings your like and source the file at login. Example config variables are provided in csh and bash style. If you use a different shell you may need to change the SAR_CONFIG syntax. For example: csh: setenv SAR /home/insar bash: export SAR=/home/insar Read the instructions in ROI_PAC_3_0_1/ROI_PAC/DOC/SAR_CONFIG. Copy this file into the directory ROI_PAC_3_0_1/ROI_PAC and edit the appropriate lines. You will have to source this file every time that you want to use ROI_PAC. It will set your path environment so that the necessary scripts will be available on the command line. % cp ROI_PAC_3_0_1/ROI_PAC/DOC/SAR_CONFIG ROI_PAC_3_0_1/ROI_PAC/. % vi ROI_PAC_3_0_1/ROI_PAC/SAR_CONFIG (edit paths) % source SAR_CONFIG In addition to the paths to ERS orbit files (SAR_PRC_DIR and SAR_ODR_DIR) or Envisat orbit files (POR_DIR and VOR_DIR), you will also need to define the INT_BIN and INT_SCR directories. To do this, add the following lines to SAR_CONFIG. export INT_BIN="/full_path/ROI_PAC_3_0_1/ROI_PAC/INT_BIN" export INT_SCR="/full_path/ROI_PAC_3_0_1/ROI_PAC/INT_SCR" Instead of using export for the bash shell, use the setenv syntax if you are using the csh or sh shell. You can also add the path to mdx, getorb, or other related software that you might install. export MDX="/software/mdx/bin" export FFTW_LIB="/software/ROI_PAC_3_0_1/NetInst/fftw-071005-1457/lib" export PATH="$PATH:$INT_BIN:$INT_SCR:$MDX" 6. Update Path To Perl The path to the perl executable may be different on your machine than is used in the ROI_PAC scripts. You can check if this step is necessary by comparing the paths in the following outputs: % cd ROI_PAC_3_0_1/ROI_PAC/INT_SCR % grep perl make_raw.pl #!/usr/bin/perl 13

% which perl /usr/bin/perl The example shown above shows that no changes are necessary. If the paths are different, there is a simple script in ROI_PAC_3_0_1/ROI_PAC/INT_SCR that will edit this path for you in all of the perl scripts. % cd ROI_PAC_3_0_1/ROI_PAC/INT_SCR % chgperlpath.pl 7. Celebrate You are now ready to process your own SAR data. Create a workspace where you will process future data. You may also want to create a new directory elsewhere on your system where you can archive your DEM and orbit files. Update SAR_CONFIG with the new location of the orbit files. Remember to source your SAR_CONFIG in each new shell before you start to process data. Alternatively, you can add a line to the file that initializes your shell environment upon startup (such as.cshrc or.bash_profile). Some notes on compiling ROI_PAC for Mac 10.6.x (Snow Leopard) I recently compiled ROI_PAC on a 64-bit Mac (OS 10.6.8, little endian). Here are notes on the procedure. 1. Obtain Compilers The Snow Leopard operating system does not include any compilers by default. In order to obtain compilers, you must install XCode, which is the Mac developer software. The newest version of XCode (4.2.x) is not available for free it is $99 if you don t already have a license. The older XCode (3.2.x) was free, but is no longer downloadable. If you can obtain a.dmg for XCode 3.2.x, this can be installed for free. All versions of XCode include a gcc compiler. Therefore, simply installing any version of XCode will allow you to install and compile the FFTW library. However, you will get stuck after this point if you have not also installed a separate fortran compiler (in other words, no fortran compiler is included with XCode 3.2.x). The following website has resources for installing gfortran: http://r.research.att.com/tools/ The first.dmg (4.2.3) on the website will not work with XCode you will not be able to get ROI_PAC to link to FFTW during compilation if you install gfortran4.2.3. You must instead install the gfortran-42-5xxx version of gfortran (whichever matches your XCode version). 2. Build Without Multibuild I found that building ROI_PAC with these compilers was easier without using multibuild.sh. Following the instructions in /ROI_PAC_3_0_1/ROI_PAC/INSTALL, I did the following: % cd /ROI_PAC_3_0_1/ROI_PAC/ 14

% LDFLAGS=-L/$FFTW_LIB_DIR F77=gfortran./configure -- prefix=/roi_pac_3_0_1/roi_pac/int_bin % mkdir /ROI_PAC_3_0_1/ROI_PAC/INT_BIN % sudo make % sudo make install I found that specifying the fortran compiler was necessary, as was setting the LDFLAGS option (even though $FFTW_LIB_DIR was already exported). Finally, I put the prefix option in order to direct the executables to INT_BIN (otherwise I m not sure where they would end up). After this, I proceeded with the instructions above to set up SAR_CONFIG and so forth. 15

Appendix 2: ROI_PAC file types and file formats In outline, the files output by ROI_PAC have 4 basic types: 1) ASCII files used for input or output by programs (suffixes:.out,.in,.off: more details below) 2) Binary files as real or complex files (see below) RMG format (Names for JPL radar pioneer Richard M. Goldstein) are made up of real*4 (32 byte) numbers in two arrays side-by-side. The two arrays often show the magnitude of the radar image and the phase although not always (sometimes the phase is the correlation. The length and width of each array are given as lines in the metadata (.rsc) file. Thus the total width of the binary file is (2 * width) and the data are stored as (Magnitude, magnitude, magnitude, Phase, Phase, Phase, ) complex or c8 files contain real and imaginary values that are stored in the binary file as (real, imaginary, real imaginary, etc.) 3) ASCII files associated with each binary file containing metadata (end with.rsc resource file); and a record of the changes made to the metadata file (.rsc.hst history file) 4) ASCII log files that record the commands that have been run in each directory where ROI_PAC is run. The log files provides a record of the commands that have been run and the times that these were run. During debugging you can often just copy and paste these commands onto the command line modifying one or more values. The log1 file shows the information that was written out by the scripts to the screen, but unfortunately it usually does not include error messages. We now describe the specifics of these files in categories of input file (user-created) and output files (generated automatically from ROI_PAC) divided by the suffix to the file name: Input files: *.proc = ASCII text file specifying parameters used in processing and there are two main types: int*.proc files for creating the interferograms (required and the suffix is allowed to be different) and optional roi.proc or (DATE).proc files that are used to create the slc s. See Appendix 4 for details on the different parameters that can be set. *.dem = binary file with digital elevation model in lat-long or UTM coordinates, signed integer 2-byte values (in meters unless scaling specified). An important question to consider when comparing InSAR results to GPS or others is whether the heights in the DEM file refer to heights relative to the ellipsoid or the Geoid (SRTM refers to Geoid heights). The.dem and.dem.rsc file can be automatically generated by the script get_srtm.pl available at http://aws.roipac.org/cgi-bin/moin.cgi/contribsoftware or you can create your own files. The format for the.rsc file is as follows: WIDTH number of columns FILE_LENGTH number of rows 16

X_FIRST longitude of upper left corner (does it refer to center of upper left pixel?) Y_FIRST latitude of upper left corner (does it refer to center of upper left pixel?) X_STEP longitude pixel size in degrees for latlon, meters for UTM Y_STEP latitude pixel size in degrees for latlon, meters for UTM X_UNIT degrees or meters Y_UNIT degrees or meters Output files: *.off = ASCII text file of offsets measured between two images columns 1=X, 2=ΔX, 3= Y, 4=ΔY, 5=Signal-to-noise ratio, other columns are three components of the match covariance *.in = ASCII text file created by ROI_pac scripts used as input for a compiled program *.out = ASCII text informational output of a program *.hgt = binary file with simulated SAR amplitude image and elevation in radar coordinates, real 4-byte values band interleaved by line (BIL or rmg ) *.slc = complex real 8-byte binary file containing real and imaginary parts of the singlelook complex (SLC) image (and multilooked versions of the SLC) *.cor = binary file with average amplitude of SAR images used to form an interferogram and correlation measure of coherence, real 4-byte values band interleaved by line (BIL or rmg ) *.raw = binary file of raw data, I,Q (see section II for explanation) 1-byte integer values for each echo sample *.aff = ASCII text file of affine transformation to map simulated image to actual SAR image *.unw = binary file with SAR amplitude image and unwrapped phase, real 4-byte values band interleaved by line (BIL or rmg ). The units in the file are radians and can be converted to cm by multiplying by the radar wavelength and dividing by 4*pi. NOTE: phase change values in this file are relative that is zero radians of phase change could actually be -1 m, +1 m, or some other value that must be otherwise constrained. *.flg = binary file with flags used and resulting from unwrapping with standard unwrapper, 1-byte values with flags set in bits * int = complex real 8-byte binary file containing real and imaginary parts of the interferogram (can also be read as real or float values band interleaved by pixel) 17

.amp = binary file with amplitudes of the two SAR images used to form an interferogram, real 4-byte values band interleaved by pixel (can also be read as complex 8-byte values) *.msk = binary file with SAR amplitude image and coherence with zeros in masked out areas, real 4-byte values band interleaved by line (BIL or rmg ) *.trans = binary file with inverse mapping transformation from SAR to DEM coordinates, two bands are range and azimuth pixel locations of SAR for each DEM pixel, real 4-byte values band interleaved by line (BIL or rmg ) The file names before the suffix are descriptive of the steps that were taken to create that file. For example: *rlks* Specifies the number of range looks taken from the full resolution interferogram or, for a geocoded file, from the resolution of the full resolution geocoded file filt_* means that the file has been filtered by the filter.pl script *-sim* means that the simulated topographic interferogram has been removed flat_* the file has been flattened (a.k.a. orbital effects have been removed) geo_* file has been geocoded SIM_* The DEM has been converted to radar coordinates (simulated interferogram) using orbital information but no fine adjustment of the position has been made (see radar_*) radar_* The DEM has been converted to radar coordinates (simulated interferogram) using orbital information and a fine adjustment of the position has been made (this file is created after SIM_*) radar_*.unw is created by diffnsim.pl and includes the orbital & topographic effects radar_*.hgt is created by rect.pl and includes only the topographic effects ramp_* The orbital phase ramp created by diffnsim.pl with no topographic effects *SIM* or *ODR* or *PRC* or *HDR* means that the orbital effects have been removed using the given type: ODR = Delft PRC = DPAF SIM = re-estimated baselines HDR = header file (or for Envisat, some precise orbits are still called HDR) 18

Appendix 3: ROI_PAC processing flow: Script-by-Script Before you get started, you need the following 5 things: 1) Orbit files may need to be downloaded directly from a space agency or other institutions it depends on which satellite you are using. See Appendix 6 2) InSAR processing software: see: Appendix 1 for installing ROI_PAC. To make sure it is working properly it is recommended to try the test data and ensure that the processing results are correct. 3) Digital Elevation Model (Definitely try SRTM if available (between 60 degrees north and 56 degrees south); The script get_srtm.pl will allow you to download the software and convert it to ROI_PAC format by specifying a few simple parameters (lat/lon, global vs. US versions, etc.) The latest version is available at: https://github.com/scottyhq/insar_scripts/tree/master/dem 4) Viewing software: http://aws.roipac.org/cgi-bin/moin.cgi/viewing_results also see Appendix 8 5) Raw data: for information on how to download, see Appendix 7 Step 1: Create the proper directory structure (two subdirectories with the raw data from the two different dates to be combined. Format could be YYMMDD). Then within each subdirectory, run the following command for ERS data, where DATE = YYMMDD (or whatever date format you use for the directory name). Run make_raw.pl ORBIT_TYPE LEADER_FILE DATE There are different scripts if you are using JERS, RADARSAT, ENVISAT, or ERS data downloaded in CEOS format from ASF. Those that are not available in ROI_PAC are available at: http://aws.roipac.org/cgi-bin/moin.cgi/satelliteissues. However, once you've made raw, the following steps are more-or-less the same for all data types. Data ingestion: make_raw_(sat).pl The make_raw script will prepare the files for processing in ROI_PAC, performing an initial check of the file, reformatting the data, locating the appropriate orbit file, and performing a Doppler computation. There are different ingestion programs for each satellite type ERS-1 and ERS-2: use make_raw.pl For data formatted at the Alaska Satellite Facility use make_raw_asf.pl Envisat: use make_raw_envi.pl ALOS: use make_raw_alos.pl JERS-1: use make_raw_jers.pl 19

COSMO-SkyMed (CSK): (to be released in version 3.1) raw, use make_raw_csk.csh SLC, use make_slc_csk.csh TerraSAR-X and TanDEM-X (TSX & TDX): (to be released in version 3.1) SLC, use make_slc_tsx.csh Radarsat-1 has two data products from the Alaska Satellite Facility CEOS: use make_raw_rsat-ceos.pl STF: use make_raw_radarsat_swath.pl (Not yet released) You can run make_raw_(sat).pl with no arguments to see a detailed usage page. As an example, to run with ERS, cd to the directory containing the master SAR scene and run the following command (using Delft ODR orbits, you could also use the HDR, header file orbits or PRC orbits): $ make_raw.pl ODR SARLEADER(DATE1) (DATE1) Repeat the steps: cd to the directory of the slave SAR scene, and run make_raw_xxx.pl adjusting the date and filename appropriately. You are now ready to produce an interferogram. NOTE: make_raw_(sat).pl can concatenate multiple frames together you do not need to run each frame separately. For the concatenation to work, you need to have all of the frames together in the same directory and have their file names be in numerical order so that the program can figure out which goes first, second, third, etc. based just on the file names. For Envisat and ALOS data, the files usually come in the correct format for concatenation the file time (Envisat) or frame number (ALOS) usually appear in the file name. For ERS, depending on how you receive the data, you may need to rename the binary data and leader files to have each frame be in the correct order. The output files are: $date.raw unpacked raw data 8 bits I,Q for each sample, one line per echo record, ERS has 412 bytes extra at start of lines $date.raw.rsc metadata for raw data hdr_data_points_$date.rsc orbit data reformatted other intermediate files, including dop.unw output of programs to measure Doppler centroid of data (fit put into.raw.rsc) The other programs called by make_raw_(sat).pl include (information here may not be completely up-to-date, please read the scripts themselves for the more details); make_raw.pl: new_parse finds missing lines and adds duplicates, finds overlapping lines and removes 20

delay_shift shifts the lines in the raw data to remove offset (called swst) due to satellite geometry leader2rsc takes information from the leader file to put into the.rsc file state_vector.pl -- calculates satellite position & velocity at requested epoch dopiq GetPeg.pl make_raw_envi.pl: asa_im_decode state_vector.pl -- calculates satellite position & velocity at requested epoch scan_doppler.pl -- make_raw_jers.pl autofocus.pl JoinJData concatenate scenes and remove raw data header Calc_squint.pl leader2rsc takes information from the leader file to put into the.rsc file mlcc used in Doppler centroid estimation dopiq used in Doppler centroid estimation make_raw_alos.pl: ALOS_pre_process ALOS_merge ALOS_fbs2fbd ALOS_fbd2fbs state_vector.pl -- calculates satellite position & velocity at requested epoch make_raw_rsat-ceos.pl: state_vector_rsat.pl -- calculates satellite position & velocity at requested epoch intert2terrest 21

extract_ut1_utc parse_rsat.le or parse_rsat.be modify rough raw data into conditioned raw data dopiq-new used in Doppler centroid estimation Step 2: Create the proper processing file called "date1-date2.proc" Run process_2pass.pl "date1-date2.proc" [DoItFrom] [EndItAt] (see table below for some possible [DoItFrom] or [EndItAt] points) process_2pass.pl is the most commonly run script, but others (http://geophysics.eas.gatech.edu/people/anewman/classes/mgm/insar/roi_pac_do CS/process_index/perl_scripts.html) are sometimes needed [this list is incomplete and a little out of date, but it's better than nothing!]. If you are exceedingly lucky, process_2pass.pl can go from the raw data to making an interferogram to removing the orbital effects ("flattening") to removing the topographic effect to unwrapping to geocoding in a single run. More likely, you are going to start and stop this flow at various points to fix errors or otherwise change the parameters (see the table below). There are numerous such "start" and "stop" points listed below, but we highlight (in purple bold) the ones that you will use most frequently. To run the process to the end, use done for [EndItAt]. 22

[DoItFrom] [EndItAt] point raw roi_prep orbbase slcs offsets resamp flatorb full_res done_sim_off done_sim_removal begin_filt filtered make_mask unwrapped redo_base sim_removal_bsim unwrapped_bsim done Comments Always start here after running make_raw.pl Create input files for SAR processor Calculate baselines Create single-look-complex interferograms Co-register two slcs: Frequently restart here after (problem #2a on this list) Resample slave scene to master coordinates "flatten" scene and remove orbital ramp Good stopping point: have created interferograms and correlation files Calculate offsets between interferogram and DEM Good stopping point: have removed the topographic effects from the flattened interferogram filter the interferogram done filtering create mask for unwrapping Good stopping point: Flattened interferogram with topography removed is unwrapped Empirically re-estimate the baselines remove topo from newly re-flattened interferogram unwrap newly re-flattened interferogram Final stopping point: Put flattened unwrapped interferogram with topography removed in geographic coordinates How long will it take? Processing a single frame interferogram takes on the order of an hour (using the default parameters, although it can take longer if you have a noisy interferogram) from raw data to the final interferogram with the orbital and topographic effects removed, unwrapped and placed in geocoded coordinates. Of course this does depend on your computer processing speed and whether you use $concurrent_roi=yes among other options. All output files and directories will be placed in the directory where param.proc tells them to. If the script terminates successfully, the final line of terminal output will be That s all folks. How much memory do I need? For most satellites besides ALOS, you can process most data with 2 Gb of RAM. For ALOS you need at least 4-8 Gb. How much disk storage do I need? For a single frame of ERS data (other satellites may be bigger or smaller), the slc s are each about 1.5 Gb, the full resolution interferograms are about 1 Gb. Thus, the complete int* directory is of order 6 Gb and thus including raw data and slc s a single frame completely processed to done is about 10 Gb. Multiply this number by the number of frames to get an estimate. 23

process_2pass.pl calls secondary scripts that are listed here in the order with which they are called and a brief description of their purpose (information here may not be completely up-todate, please read the scripts themselves for the more details): [DoItFrom= raw] raw2ampintcor.pl is a script that calls other scripts to go from the steps of making the slc s, interferograms and correlation files dopav.pl -- checks to make sure the bandwidth of the two slcs are within reasonable limits. If not, it removes the slc files which kills the process_2pass.pl Calculates the mean Doppler centroid for the pair of images and common bandwidth uses: (date).raw.rsc files makes: roi.dop.rsc files roi_prep.pl -- Creates the input files for the roi.pl script uses: (date).raw; (date).raw.rsc; roi.dop; (date).proc [optional] roi.proc [optional] makes: (date).slc.rsc (date)_roi.in -- Input file for the roi program [EndItAt= roi_prep] calls: GetPeg.pl calculates peg point on the ground baseline.pl -- calculates baseline between image pair from orbits or header information uses: (date1).slc.rsc; (date2).slc.rsc makes: (date1)_(date2)_baseline.rsc [EndItAt= orbbase] calls: state_vector.pl (calculates satellite position & velocity at requested epoch) roi.pl -- Creates the slcs from the raw data uses: (date).raw; (date).raw.rsc; roi.dop; (date).proc [optional] roi.proc [optional] makes: (date).slc; (date).slc.rsc (date)_roi.out output file for the roi program calls: the roi -- FORTRAN program creates the slc s; length.pl which updates the rscfile with the new length of the file after roi is complete 24

look.pl -- Takes specified number of looks of an imagefile. This script is called several times throughout process_2pass.pl, but we will only refer to it at this first usage uses: (date).slc; (date).slc.rsc [EndItAt= slcs] [DoItFrom= slcs] makes: (date)_rlks.slc; (date)_rlks.slc.rsc make_offset.pl -- computes offset between two slcs as a function of x, y in the reference image. The program calculates the offsets twice, once at large spacing between searches with a large search window in order to get a rough estimate of the offset (*ampcor_gross*) and then with a denser spacing between searches and a smaller search window (*ampcor*) uses: both (date).slc and (date).slc.rsc files makes: gross_x; gross_y; (date1)_ (date2)_ampcor_gross.in; (date1)_ (date2)_ampcor_gross.off; (date1)_ (date2)_cull_gross.off; (date1)_ (date2)_ampcor_gross.out; (date1)_ (date2)_ampcor.in; (date1)_ (date2)_ampcor.off; (date1)_ (date2)_cull.off; (date1)_ (date2)_ampcor.out; fitoff_ampcor_gross.out fitoff_ampcor.out; [EndItAt= offsets] [DoItFrom= offsets] calls: offset.pl -- which actually calculates the offsets once all files are set up (this is the program that is called twice for the gross and fine offsets) fitoff selects good points from the ampcor file and puts them in the *cull* file resamp.pl -- makes the interferogram and amplitude files uses: slc and slc.rsc files; (date1)_ (date2)_cull.off; makes: (date1)_ (date2).int; (date1)_ (date2).int.rsc (date1)_ (date2).amp; (date1)_ (date2).amp.rsc (date1)_ (date2)_resamp.in; (date1)_ (date2)_resamp.out calls: resamp_roi -- FORTRAN program that actually makes the interferogram after putting the slc s in the same reference frame. Fits a second order polynomial to the culled offsets and uses this to resample the 25

[EndItAt= resamp] [DoItFrom= resamp] slave slc to the master. Interferogram formed by multiplying the complex pixel of master scene by the complex conjugate of the slave scene add_rmg.pl -- This is a utility program used throughout the scripts that works on two files of the same size and will add or subtract rmg them together or you can not add/subtract but mask certain values. You have the choice of outputting zero at a given pixel when one of the images has a zero in it or both do. In this location in the script, the program creates a file that is the size of the interferogram but that is all set to $ref_height (default is zero) to be used by diffnsim.pl to flatten the interferogram uses: junk.unw makes: reference.hgt; reference.hgt.rsc diffnsim.pl -- are then used to flatten the interferogram, meaning that the orbital effects are removed but not the topographic effects uses: (date1)_ (date2).int; makes: flat_(date1)_ (date2).int; ramp_orbit_type.unw diffnsim_flat*.int.in [EndItAt= flatorb] [DoItFrom= flatorb] calls: diffnsim -- computes the differential interferogram (in this instance, it only removes the orbital effects) make_cor.pl -- creates an rmg file with average amplitude and correlation between images uses: flat_(date1)_ (date2).int; (date1)_ (date2).amp makes: (date1)_ (date2).cor; calls cchz_wave -- which calculates the correlation using a 5x5 triangular weighted window replace mag.pl -- replaces the magnitude from infile1 with the magnitude from infile2. Replaces the magnitude of the correlation file with the average from the two scenes uses: flat_(date1)_ (date2).int makes: (date1)_ (date2).cor; calls: rmg2mag_phs; cpx2mag_phs; mag_phs2rmg; mag_phs2cpx; -- These are utility programs written in C used throughout the perl scripts to 26

[EndItAt= full_res] [DoItFrom= full_res] separate rmg or cpx files into their magnitude and phase components and then combine them together again. dem2diff.pl -- is a script that calls other scripts to go from the original interferogram to one that has both the orbital and topographic effects removed make_sim.pl -- makes a simulated interferogram that only includes the effects of topography that will be removed from the interferogram created in the raw2ampintcor.pl script. Uses:.dem;.dem.rsc The dem file format is discussed in appendix 2 Makes:.dem.slp (if it doesn t already exist) This is a dem slope file SIM_raw.hgt first guess of dem converted into radar coordinates. This files has holes in it and must be interpolated using the Aik_resamp.in file and the Aik_resamp program to make SIM_rlks.hgt SIM.orrm orbit information to determine the location of the satellite relative to the simulated interferogram IntSim.in; IntSim.out These files are created by are not used: GPS.in; GPS.out; simfile; simoutfile Calls: make_orrm.pl -- creates the SIM.orrm file Gradient.pl -- (if the.slp file doesn t exist) creates the slope file IntSim -- the program that actually does the calculations to convert from geographic to radar coordinates Aik_resample interpolates SIM_raw.hgt to fill in holes caused by projecting DEM to radar coordinates (especially on steep slopes) or because DEM and interferogram had different pixel spacings Length.pl -- which updates the rscfile with the new length of the file Synth_offset.pl -- Finds the offset field between the synthetic interferogram and satellite images because the orbital information does not align them perfectly Uses: (date1)-(date2)_rlks.cor SIM_rlks.hgt Makes: ampmag_gross.in ampmag_gross.off ampmag_gross_cull.off ampmag_gross.out ampmag.in ampmag.off ampmag.out ampmag_cull.off cull.out Calls: offset.pl -- which actually calculates the offsets once all files are set up 27

fitoff selects good points from the ampmag file and puts them in the *cull* file [EndItAt= done_sim_off] [DoItFrom= done_sim_off] Synth2radar.pl -- Transforms the synthetic interferogram in radar coordinates to precisely align with the interferogram using the offsets calculated from syth_offset.pl uses:sim*.hgt; cull.out makes:radar_*.hgt; (date1)-(date2)_*rlks.aff calls:rect.pl morphs an rmg or cpx file given affine transformation parameters find_affine.pl extracts the affine matrix and translation vector from cull.out diffnsim.pl looks down the interferogram, removes the orbital effects, and subtracts the simulated topography uses: (date1)-(date2).in; radar_*rlks.hgt makes: (date1)-(date2)-sim-*rlks.int; radar_*rlks.unw; diffnsim*.int.in calls: diffnsim -- computes the differential interferogram (in this instance, removing the orbital and topographic effects) [EndItAt= done_sim_removal] [DoItFrom= done_sim_removal] radarseismodel.pl optional script (if $model is not null ): builds the radar files corresponding to seismic deformation models: calls geo2radar.pl; disp2phas.pl; Aik_resample; rect.pl; add_rmg.pl; rmg2mag_phs; mag_phs2rmg removemodel.pl optional script (if $model is not null ) removes the model from the interferogram rect_cut.pl optional script (if $man_cut is not null ) rectifies a BYTE file given an affine transformation [DoItFrom= begin_filt] int2filtmaskunwrap.pl -- is a script that calls other scripts to go from the steps of filtering, masking, and unwrapping the interferogram filter.pl filters an interferogram using the power spectrum filtering method (Goldstein and Werner, 1988) (psfilt is the default) or the adaptive filtering method (adapt_filt) which is rarely used. 28

Uses: (date1)-(date2).int makes:filt_(date1)-(date2).int calls: psfilt program that actually does the power spectrum filtering adapt_filt.pl program that does the adaptive filtering rmg2mag_phs; cpx2mag_phs; mag_phs2cpx; mag_phs2rmg -- These are utility programs written in C used throughout the perl scripts to separate rmg or cpx files into their magnitude and phase components and then combine them together again. [EndItAt= done_filt] [DoItFrom= done_filt] make_mask.pl computes a mask from an interferogram to remove low correlation areas. Used in branch-cut unwrapping or to mask out areas in snaphu unwrapping uses: makes:phase_var*rlks.msk calls: phase_slope -- removes a local phase slope phase_mask -- makes a mask based on local slope-corrected phase variance to remove noisy areas apples $sigma_thresh add_phs rmg2mag_phs; cpx2mag_phs; mag_phs2cpx; mag_phs2rmg -- These are utility programs written in C used throughout the perl scripts to separate rmg or cpx files into their magnitude and phase components and then combine them together again. [EndItAt= make_mask] [DoItFrom= make_mask] new_cut.pl -- First step of branch-cut unwrapping algorithm -- computes the residues and builds trees to connect them Uses: filt_(date1)-(date2)-sim_rlks.int; filt_(date1)-(date2)-sim_rlks.int.rsc Makes: filt_(date1)-(date2)-sim_rlks_cut.flg; filt_(date1)-(date2)-sim_rlks_cut.flg.rsc calls: residues -- calculates phase residuals from filtered and sloperemoved interferograms trees -- draws phase cuts to connect the residues (this program can take days or longer to run if the file is large and/or noisy if so, consider running on a looked down version). unwrap.pl -- unwraps an interferogram using the branch-cut algorithm using a.glf file. Leaves gaps in the unwrapped interferogram where correlation is below the threshold. 29

Uses: filt_(date1)-(date2)-sim_rlks.int; filt_(date1)-(date2)-sim_rlks_cut.flg; Phase_var*rlks.msk Makes: filt_(date1)-(date2)-sim_rlks_cthres.flg; THRES is the UnwrappedThreshold set in the.proc file filt_(date1)-(date2)-sim_orbit_*rlks_cthres.unw; this is the filtered, unwrapped, flattened interferogram with the topography removed. Any voids are from regions that did not unwrap. If the whole file is blank see the troubleshooting section. Calls: rmg2mag_phs; mag_phs2rmg -- These are utility programs written in C used throughout the perl scripts to separate rmg or cpx files into their magnitude and phase components and then combine them together again. corr_flag -- combines the unwrapping mask with the phase cut trees applying the coherence threshold $UnwrappedThreshold grass -- unwraps the filtered interferogram phase between the tress of phase cutes, using the mask and starting at the $unw_seedx, $unw_seedy location which is defined as zero. [EndItAt= unwrapped] [DoItFrom= unwrapped] add_rmg.pl only used with old unwrapper to combine phase_var*.msk with filt_(date1)-(date2)-sim_rlks_cthres.unw to create low_cor*.msk with zeros in areas that didn t unwrap add_rmg.pl only used with old unwrapper to combine low_cor*.msk with radar_*.hgt to create basest*rlks.msk to use in baseline re-estimation add_rmg.pl only used with old unwrapper and when $model is not equal to null to combine baseest*rlks.msk with seismic model to create basest*rlks.msk to use in baseline re-estimation add_rmg.pl -- This is a utility program used throughout the scripts that works on two files of the same size and will add or subtract rmg them together or you can not add/subtract but mask certain values. You have the choice of outputting zero at a given pixel when one of the images has a zero in it or both do. In this location in the script, the program combines the unwrapped file with the file that includes the topographic and orbital effects to make what is effectively an unwrapped original interferogram with no orbital or topographic effects removed uses: filt_(date1)-(date2)-sim_rlks_cthres.unw; radar*rlks.unw makes: total_(date1)-(date2)_*rlks.unw and the identical file pha4baseest.unw 30

add_rmg.pl only used when $model is not equal to null to remove seismic model from total_(date1)-(date2)_*rlks.unw to make new pha4baseest.unw phase2base.pl used to re-estimate the baselines from the unwrapped interferogram and the DEM in corrected radar coordinates. uses:pha4baseest.unw; radar*rlks.hgt; baseest*rlks.msk; phase2base.in [EndItAt= redo_base] [DoItFrom= redo_base] makes:phase2base.out calls:baseestq fortran program that actually calculates quadratic baseline diffnsim.pl looks down the interferogram, removes the orbital effects using the reestimated baselines, and subtracts the simulated topography uses: (date1)-(date2).in; radar_*rlks.hgt makes: (date1)-(date2)-sim_sim*rlks.int; radar_sim*rlks.unw; diffnsim*sim*.int.in calls: diffnsim -- computes the differential interferogram (in this instance, removing the topographic effects and orbital effects from the re-estimated baselines) [EndItAt= sim_removal_bsim] [DoItFrom= sim_removal_bsim] add_rmg.pl -- This is a utility program used throughout the scripts that works on two files of the same size and will add or subtract rmg them together or you can not add/subtract but mask certain values. You have the choice of outputting zero at a given pixel when one of the images has a zero in it or both do. In this location in the script, the program removes the re-estimated orbital and topographic effects from the original unwrapped interferogram uses:; total_(date1)-(date2)_*rlks.unw; radar_sim*rlks.unw makes: filt_(date1)-(date2)-sim_sim_*rlks_cthres.unw add_rmg.pl only used when $model is not equal to null to remove seismic model from total_(date1)-(date2)_*rlks.unw to make new filt_(date1)-(date2)- sim_sim_*rlks_cthres.unw [EndItAt= unwrapped_bsim] 31

[DoItFrom= unwrapped_bsim] radar2geo.pl transforms the interferogram in radar coordinates into the geographic coordinates of the DEM make_geomap.pl creates the look-up table to convert from radar to geographic coordinates uses: *.dem; SIM.orrm makes (date1)-(date2)_*rlks.trans; *.dem.slp (if it doesn t already exit) IntSim.in; IntSim.out calls:intsim -- creates the look-up file (date1)-(date2)_*rlks.trans length.pl geocode.pl uses the look-up file ((date1)-(date2)_*rlks.trans ) to convert interferogram to geocoded file uses: ((date1)-(date2)_*rlks.trans; filt_(date1)-(date2)-sim_orbit_*rlks_cthres.unw makes:rect_lookup.in; geo_(date1)_(date2).unw calls:rect_lookup actually does the transformation from radar to geographic coordinates length.pl geomodel.pl only used if $model is not null creates the geocoded interferograms minus the seismic deformation models [EndItAt= done] 32

Appendix 4: User defined options for ROI_PAC processing The int*.proc file (see Appendix 4) must contain the following: SarDir1 = name of image directory 1 (master scene) with raw data SarDir2 = name of image directory 2 (slave scene) with raw data IntDir = name of interferogram directory (e.g., int_031101_060916), better to include full path The following commands are all options within the int*.proc file (with the default values): $DEM= path to the location of the.dem and.dem.rsc file If no DEM is available you can use the process_npass.pl method (this hasn t been used for many years, so it is probably out of date) $concurrent_roi (no) when =yes runs roi on both scenes at the same time. Only use if enough CPU s and RAM are available $GeoDir ("GEO") Location to put the geocoded interferograms $FilterStrength (0.75) coefficient in the power spectrum filtering algorithm of psfilt and filter.pl bigger numbers= more filtering. The complex FFT is taken of a twodimensional square of pixels, then raised to the power of this coefficient, and finally an inverse FFT is taken. This removes high frequency noise, but beware: sharp discontinuities (like faults) have power at all frequencies and this process smooths them out. $UnwrappedThreshold (0.1) correlation threshold for unwrapping with the branch-cut algorithm of unwrap.pl Smaller values mean that more of the image will be unwrapped, potentially including more errors $OrbitType ("ODR") The type of orbital parameters to use in processing to remove the orbital effects. $BaselineType ($OrbitType) I m not sure why you would change this from the default value. $Rlooks_sim (4) Specifies the number of looks to take of the full resolution interferogram before removing the topographic effects from the DEM (a.k.a. the simulated interferogram). The default value of 4 comes from the ERS full resolution pixel resolution (~20 m) and the SRTM global resolution (~90 m). That is, int(90/20) = 4. For other DEM s or satellite pixel resolutions, other values should be used. $Rlooks_int ($Rlooks_sim) $Rlooks_unw ($Rlooks_sim) Number of looks to take of the full resolution interferogram before doing the unwrapping. 33

$Rlooks_sml (16) $pixel_ratio (5) The ratio between the range_ground_pixel_size and the azimuth_pixel_size to be used when creating the interferogram so that the pixels are square. These values were taken from ERS where the azimuth pixel size is ~4 m/pixel and the range ground pixel size is ~20 m/pixel (slant range pixel size divided by sine(incidence angle)), so we want to compress 5 azimuth pixels together (20/4 = 5). For other satellites, you should change this number or your interferogram will look stretched out. $Alooks_sml ($Rlooks_sml*$pixel_ratio) $usergivendop1 (0) $usergivendop2 (0) $unw_seedx (-9999) starting point in x direction for branch-cut unwrapping algorithm (default is image center) See next section of this Appendix for more details. $unw_seedy (-9999) starting point in y direction for branch-cut unwrapping algorithm (default is image center) See next section of this Appendix for more details. $x_start (0.01) Mean offset between slc s in the range (x) direction $y_start (0.01) Mean offset between slc s in the azimuth (y) direction $Threshold_mag (5.0e-5) Used in creating.msk file $Threshold_ph_grd (0) Used in creating.msk file $sigma_thresh (1.0) Used in creating.msk file (1.4 is a good value larger sigma_thresh mean that fewer values will be masked out) $smooth_width (5) Used in creating.msk file $slope_width (5) Used in creating.msk file $mapping ("dem_based") $cleanup ("no") Deletes slc and *gross* files when reamp.pl is complete $CO_MODEL ("NULL") Use a co-seismic deformation model in the geographic coordinates of the DEM $INTER_MODEL ("NULL") Use an inter-seismic deformation model in the geographic coordinates of the DEM 34

$Filt_method ("psfilt") type of algorithm to use in filter.pl, alternative is adapt_filt $unw_method ("old") type of unwrapping algorithm to use default is branch-cut, but other options are icu and snaphu. See next section of this Appendix for more information. $flattening ("topo") specifying topo means that the baselines should be re-estimated after the unwrapping step before geocoding (the first flattening in raw2ampintcor.pl will use the orbit files as always). Specifying orbit means that the baselines will not be reestimated $do_sim ("yes") If set to no the make_sim.pl step will be skipped. You might choose no if you are processing multiple interferograms in a time series that will be coregistered so that you can use the same DEM converted to radar coordinates for all of them. $do_mod ("yes") #could be: no,gp 11.10.04 $unw_mod ("yes") #could be: no,gp 11.10.04 $MAN_CUT ("NULL") #filename of man_cut (SIM) $BaselineOrder ("QUAD") When calculating how the baseline changes as a function of line number in the interferogram include quadratic terms (alternative is only linear terms: LIN ) $MPI_PARA ("no") $NUM_PROC (1) Number of processors to use $ROMIO ("no") $ref_height (0.) Sets the reference elevation The optional roi.proc or (DATE).proc files have the following options that can be set (see roi_prep.pl script for details on what each variable means): $before_z_ext (int($az_frac * $synth_apert_samps + 0.5)) Use this command to crop the top of the image by a certain number of pixels (a negative number removes or crops pixels while a positive number adds pixels or zero-pads the image) $after_z_ext (int($az_frac * $synth_apert_samps + 0.5)) Use this command to crop the bottom of the image by a certain number of pixels (a negative number removes or crops pixels while a positive number adds pixels or zero-pads the image) $near_rng_ext (int($chirp_samps * $rg_frac )) Use this command to crop the image in the near range (small x or left side of the image) direction by a certain number of pixels 35

(a negative number removes or crops pixels while a positive number adds pixels or zeropads the image) $far_rng_ext (int($chirp_samps * $rg_frac )) use this command to crop the image in the far range (large x or right side of the image) direction by a certain number of pixels (a negative number removes or crops pixels while a positive number adds pixels or zeropads the image) $valid_samples ($patch_size - $synth_apert_samps;) $number_of_patches int(($proc_end-$proc_start-($patch_size-$valid_samples))/$valid_samples + $az_round) Unwrapping: User intervention is often required to successfully unwrap an interferogram. Here are some details on the types of parameters that can be set. SNAPHU One option for phase unwrapping is to use the SNAPHU (Statistical-cost, Network-flow Algorithm for PHase Unwrapping) program developed by Curtis Chen when he was a student at Stanford. The program source code is available from the Stanford website http://www-star.stanford.edu/sar_group/snaphu/. Note that the v1.4.2 source code may have problems if it is compiled in 64-bit mode, so you may need to use the "-m32" flag in compiling it. ROI_pac version 3.0.1 (and higher) has Perl scripts that can run the SNAPHU program, including "snaphu.pl". You will need to set the environment variable MY_BIN to the directory where you have installed the "snaphu" executable program. The new "process_2pass_master.pl" processing script supports "unw_method=snaphu" and "unw_method=snaphu_mcf" specifications in the "int.proc" file. Classic unwrapper (branch-cut) The classic unwrapping algorithm in ROI_pac is the default and it is based on the Goldstein, Zebker and Werner (1988) paper. It can be selected with "unw_method=old" in the "int.proc" file. Some hints about the unwrapping procedure using the branch-cut algorithm: Setting the Starting point After calculating residues and generating the cuts in the image, the unwrapping procedure starts from the center of the scene and grows across the interferogram avoiding crossing cuts. If the starting point of the unwrapping process (by default the center of the scene) happens to be in an incoherent zone, the process stalls at the beginning and none of the image is unwrapped. You can diagnose the problem if you see the message: number of points unwrapped: 0 36

The remedy to the problem is to add keywords indicating the values of the column and line of the pixel in the image from where to start the unwrapping in the int_****.proc file. unw_seedx = unw_seedy = The pixel must be chosen in a large coherent patch of the interferogram. Making Bridges If the interferogram has large areas where the phase is not coherent, it often happens that only one patch of the interferogram around the starting point is unwrapped and disconnected coherent patches are not. ROI_PAC has the option of defining bridges between disconnected, coherent areas by setting a text file called bridge.in, placed in the int_**** folder. The file must have one line per bridge with the following format: col1 row1 col2 row2 ambig where col1/row1 are the column and row of the starting point of the bridge and col2/row2 indicate the ending point of the bridge. ambig is an integer number indicating the number of cycles between them (=0 if it is the same fringe). When the bridge.in file is set, remove all files created after the "cut" file by ROI_PAC and relaunch either unwrap.pl (read the command line in the log file) or whole process_2pass.pl with the keyword "filtered" to start the process at the unwrapping step. Repeat these steps for each new bridge to unwrap the areas of interest in the interferogram. 37

Appendix 5: Which scripts created each file generated by ROI_PAC? We used the following (date1)-(date2).proc file to generate the following files. SarDir1=(date1) SarDir2=(date2) IntDir=int_(date1)_(date2) SimDir=int_(date1)_(date2)/SIM GeoDir=int_(date1)_(date2)/GEO flattening = topo BaselineOrder = QUAD DEM=example.dem FilterStrength=0.5 OrbitType=HDR Rlooks_sim=4 Rlooks_unw=32 (and Rlooks_unw=16 in a previous run) Rlooks_geo=4 Rlooks_int=4 concurrent_roi=yes 196 Files generated: (date2)_16rlks.slc (date2)_16rlks.slc.rsc (date2)_16rlks.slc.rsc.hst (date2).slc (date2).slc.rsc (date2).slc.rsc.hst (date1)-(date2)_16rlks.cor (date1)-(date2)_16rlks.cor.rsc (date1)-(date2)_16rlks.cor.rsc.hst (date1)-(date2)_32rlks.cor (date1)-(date2)_32rlks.cor.rsc (date1)-(date2)_32rlks.cor.rsc.hst (date1)-(date2)_4rlks.cor (date1)-(date2)_4rlks.cor.rsc (date1)-(date2)_4rlks.cor.rsc.hst (date1)-(date2)_4rlks_sim.aff (date1)-(date2).amp (date1)-(date2)_ampcor_gross.in (date1)-(date2)_ampcor_gross.off (date1)-(date2)_ampcor_gross.off.rsc (date1)-(date2)_ampcor_gross.off.rsc.hst Roi.pl & look.pl Roi.pl & look.pl Roi.pl & look.pl Roi.pl Roi.pl Roi.pl Make_cor.pl & look.pl Make_cor.pl & look.pl Make_cor.pl & look.pl Make_cor.pl & look.pl Make_cor.pl & look.pl Make_cor.pl & look.pl Make_cor.pl Make_cor.pl Make_cor.pl Find_affine.pl Resamp.pl Make_offset.pl Make_offset.pl Make_offset.pl Make_offset.pl 38

(date1)-(date2)_ampcor_gross.out (date1)-(date2)_ampcor.in (date1)-(date2)_ampcor.off (date1)-(date2)_ampcor.off.rsc (date1)-(date2)_ampcor.off.rsc.hst (date1)-(date2)_ampcor.out (date1)-(date2).amp.rsc (date1)_(date2)_baseline.rsc (date1)_(date2)_baseline.rsc.hst (date1)-(date2).cor (date1)-(date2).cor.rsc (date1)-(date2).cor.rsc.hst (date1)-(date2)_cull_gross.off (date1)-(date2)_cull_gross.off.rsc (date1)-(date2)_cull.off (date1)-(date2)_cull.off.rsc (date1)-(date2)_cull.off.rsc.hst (date1)-(date2).int (date1)-(date2).int.rsc (date1)-(date2).int.rsc.hst (date1)-(date2)_resamp.in (date1)-(date2)_resamp.out (date1)-(date2)-sim_hdr_16rlks.int (date1)-(date2)-sim_hdr_16rlks.int.rsc (date1)-(date2)-sim_hdr_16rlks.int.rsc.hst (date1)-(date2)-sim_hdr_32rlks.int (date1)-(date2)-sim_hdr_32rlks.int.rsc (date1)-(date2)-sim_hdr_32rlks.int.rsc.hst (date1)-(date2)-sim_hdr_4rlks.int (date1)-(date2)-sim_hdr_4rlks.int.rsc (date1)-(date2)-sim_hdr_4rlks.int.rsc.hst (date1)-(date2)-sim_hdr_64rlks.int (date1)-(date2)-sim_hdr_64rlks.int.rsc (date1)-(date2)-sim_hdr_64rlks.int.rsc.hst (date1)-(date2)-sim_sim_4rlks.int (date1)-(date2)-sim_sim_4rlks.int.rsc (date1)-(date2)-sim_sim_4rlks.int.rsc.hst Make_offset.pl Make_offset.pl Make_offset.pl Make_offset.pl Make_offset.pl Make_offset.pl Resamp.pl Baseline.pl Baseline.pl Make_cor.pl Make_cor.pl Make_cor.pl Make_offset.pl & fitoff Make_offset.pl & fitoff Make_offset.pl & fitoff Make_offset.pl & fitoff Make_offset.pl & fitoff Resamp.pl Resamp.pl Resamp.pl Resamp.pl Resamp.pl Diffnsim.pl (2 nd time) & look.pl Diffnsim.pl (2 nd time) & look.pl Diffnsim.pl (2 nd time) & look.pl Diffnsim.pl (2 nd time) & look.pl Diffnsim.pl (2 nd time) & look.pl Diffnsim.pl (2 nd time) & look.pl Diffnsim.pl (2 nd time) Diffnsim.pl (2 nd time) Diffnsim.pl (2 nd time) Diffnsim.pl (2 nd time) & look.pl Diffnsim.pl (2 nd time) & look.pl Diffnsim.pl (2 nd time) & look.pl Diffnsim.pl (3 rd time) Diffnsim.pl (3 rd time) Diffnsim.pl (3 rd time) 39

(date1)_16rlks.slc Roi.pl & look.pl (date1)_16rlks.slc.rsc Roi.pl & look.pl (date1)_16rlks.slc.rsc.hst Roi.pl & look.pl (date1).slc Roi.pl (date1).slc.rsc Roi.pl (date1).slc.rsc.hst Roi.pl ampmag_cull.off Synth_offset.pl & fitoff ampmag_first.in Synth_offset.pl ampmag_first.off Synth_offset.pl ampmag_gross_cull.off Synth_offset.pl & fitoff ampmag_gross_first.in Synth_offset.pl ampmag_gross_first.off Synth_offset.pl ampmag_gross.in Synth_offset.pl ampmag_gross.off Synth_offset.pl ampmag_gross.off.rsc Synth_offset.pl ampmag_gross.off.rsc.hst Synth_offset.pl ampmag_gross.out Synth_offset.pl ampmag.in Synth_offset.pl ampmag.off Synth_offset.pl ampmag.off.rsc Synth_offset.pl ampmag.off.rsc.hst Synth_offset.pl ampmag.out Synth_offset.pl baseest_16rlks.msk Add_rmg.pl baseest_16rlks.msk.rsc Add_rmg.pl cull.out Synth_offset.pl & fitoff diffnsim_(date1)-(date2)- Diffnsim.pl (2 nd time) sim_hdr_4rlks.int.in diffnsim_(date1)-(date2)-sim_sim_4rlks.int.in Diffnsim.pl (3 rd time) diffnsim_flat_hdr_(date1)-(date2).int.in Diffnsim.pl (1 st time) filt_(date1)-(date2)-sim_hdr_16rlks_c10.flg Unwrap.pl filt_(date1)-(date2)- Unwrap.pl sim_hdr_16rlks_c10.flg.rsc filt_(date1)-(date2)- Unwrap.pl sim_hdr_16rlks_c10.flg.rsc.hst filt_(date1)-(date2)-sim_hdr_16rlks_c10.unw Unwrap.pl filt_(date1)-(date2)- Unwrap.pl sim_hdr_16rlks_c10.unw.rsc filt_(date1)-(date2)- Unwrap.pl sim_hdr_16rlks_c10.unw.rsc.hst filt_(date1)-(date2)-sim_hdr_16rlks_cut.flg New_cut.pl filt_(date1)-(date2)- New_cut.pl sim_hdr_16rlks_cut.flg.rsc filt_(date1)-(date2)-sim_hdr_16rlks.int Filter.pl filt_(date1)-(date2)-sim_hdr_16rlks.int.rsc Filter.pl filt_(date1)-(date2)- Filter.pl sim_hdr_16rlks.int.rsc.hst 40

filt_(date1)-(date2)-sim_hdr_32rlks_c10.flg Unwrap.pl filt_(date1)-(date2)- Unwrap.pl sim_hdr_32rlks_c10.flg.rsc filt_(date1)-(date2)- Unwrap.pl sim_hdr_32rlks_c10.flg.rsc.hst filt_(date1)-(date2)-sim_hdr_32rlks_c10.unw Unwrap.pl filt_(date1)-(date2)- Unwrap.pl sim_hdr_32rlks_c10.unw.rsc filt_(date1)-(date2)- Unwrap.pl sim_hdr_32rlks_c10.unw.rsc.hst filt_(date1)-(date2)-sim_hdr_32rlks_cut.flg New_cut.pl filt_(date1)-(date2)- New_cut.pl sim_hdr_32rlks_cut.flg.rsc filt_(date1)-(date2)-sim_hdr_32rlks.int New_cut.pl filt_(date1)-(date2)-sim_hdr_32rlks.int.rsc New_cut.pl filt_(date1)-(date2)- New_cut.pl sim_hdr_32rlks.int.rsc.hst filt_(date1)-(date2)-sim_sim_16rlks_c10.unw Unwrap.pl filt_(date1)-(date2)- Unwrap.pl sim_sim_16rlks_c10.unw.rsc filt_(date1)-(date2)- Unwrap.pl sim_sim_16rlks_c10.unw.rsc.hst fitoff_ampcor_gross.out Make_offset.pl & fitoff fitoff_ampcor.out Make_offset.pl & fitoff fitoff_gross.out Make_offset.pl & fitoff flat_hdr_(date1)-(date2)_4rlks.int Diffnsim.pl (1 st time) & look.pl flat_hdr_(date1)-(date2)_4rlks.int.rsc Diffnsim.pl (1 st time) & look.pl flat_hdr_(date1)-(date2)_4rlks.int.rsc.hst Diffnsim.pl (1 st time) & look.pl flat_hdr_(date1)-(date2).int Diffnsim.pl (1 st time) flat_hdr_(date1)-(date2).int.rsc Diffnsim.pl (1 st time) flat_hdr_(date1)-(date2).int.rsc.hst Diffnsim.pl (1 st time) GEO/ Directory filled with files from geo_(date1)-(date2).unw.rsc Geocode.pl geo_(date1)-(date2).unw.rsc.hst Geocode.pl geomap_4rlks.trans Make_geomap.pl geomap_4rlks.trans.rsc Make_geomap.pl geomap_4rlks.trans.rsc.hst Make_geomap.pl gross_x Make_offset.pl gross_y Make_offset.pl hdr_data_points_(date2).rsc Make_raw.pl hdr_data_points_(date1).rsc Make_raw.pl junk.unw.rsc.hst Add_rmg.pl 41

log log1 low_cor_hdr_16rlks.msk low_cor_hdr_16rlks.msk.rsc low_cor_hdr_16rlks.msk.rsc.hst pha4baseest.unw pha4baseest.unw.rsc phase2base.in phase2base.out phase_var_hdr_16rlks.msk phase_var_hdr_16rlks.msk.rsc phase_var_hdr_16rlks.msk.rsc.hst phase_var_hdr_32rlks.msk phase_var_hdr_32rlks.msk.rsc radar_16rlks.hgt radar_16rlks.hgt.rsc radar_16rlks.hgt.rsc.hst radar_32rlks.hgt radar_32rlks.hgt.rsc radar_32rlks.hgt.rsc.hst radar_4rlks.hgt radar_4rlks.hgt.rsc radar_4rlks.hgt.rsc.hst radar_hdr_16rlks.unw radar_hdr_16rlks.unw.rsc radar_hdr_16rlks.unw.rsc.hst radar_hdr_32rlks.unw radar_hdr_32rlks.unw.rsc radar_hdr_32rlks.unw.rsc.hst radar_hdr_4rlks.unw radar_hdr_4rlks.unw.rsc radar_hdr_4rlks.unw.rsc.hst radar_sim_16rlks.unw radar_sim_16rlks.unw.rsc radar_sim_16rlks.unw.rsc.hst radar_sim_4rlks.unw radar_sim_4rlks.unw.rsc Every file Every file Add_rmg.pl Add_rmg.pl Add_rmg.pl Add_rmg.pl Add_rmg.pl Phase2base.pl Phase2base.pl Make_mask.pl Make_mask.pl Make_mask.pl Make_mask.pl & look.pl Make_mask.pl & look.pl Rect.pl & Look.pl Rect.pl & Look.pl Rect.pl & Look.pl Rect.pl & Look.pl Rect.pl & Look.pl Rect.pl & Look.pl Rect.pl Rect.pl Rect.pl Diffnsim.pl (2 nd time) & look.pl Diffnsim.pl (2 nd time) & look.pl Diffnsim.pl (2 nd time) & look.pl Diffnsim.pl (2 nd time) & look.pl Diffnsim.pl (2 nd time) & look.pl Diffnsim.pl (2 nd time) & look.pl Diffnsim.pl (2 nd time) Diffnsim.pl (2 nd time) Diffnsim.pl (2 nd time) Diffnsim.pl (3rd time) & look.pl Diffnsim.pl (3rd time) & look.pl Diffnsim.pl (3rd time) & look.pl Diffnsim.pl (3rd time) Diffnsim.pl (3rd time) 42

radar_sim_4rlks.unw.rsc.hst Diffnsim.pl (3rd time) ramp_hdr_4rlks.unw Diffnsim.pl (1st time) & look.pl ramp_hdr_4rlks.unw.rsc Diffnsim.pl (1st time) & look.pl ramp_hdr_4rlks.unw.rsc.hst Diffnsim.pl (1st time) & look.pl ramp_hdr.unw Diffnsim.pl (1st time) ramp_hdr.unw.rsc Diffnsim.pl (1st time) ramp_hdr.unw.rsc.hst Diffnsim.pl (1st time) rect.in Rect.pl rect_lookup.in Geocode.pl reference_4rlks.hgt Add_rmg.pl & look.pl reference_4rlks.hgt.rsc Add_rmg.pl & look.pl reference_4rlks.hgt.rsc.hst Add_rmg.pl & look.pl reference.hgt Add_rmg.pl reference.hgt.rsc Add_rmg.pl reference.hgt.rsc.hst Add_rmg.pl resid.dat? RscDocDir/? SIM/ Directory filled with make_sim.pl SIM_16rlks.hgt Make_sim.pl & look.pl SIM_16rlks.hgt.rsc Make_sim.pl & look.pl SIM_16rlks.hgt.rsc.hst Make_sim.pl & look.pl SIM_4rlks.hgt Make_sim.pl SIM_4rlks.hgt.rsc Make_sim.pl SIM_4rlks.hgt.rsc.hst Make_sim.pl test? total_(date1)-(date2)_16rlks.unw Add_rmg.pl total_(date1)-(date2)_16rlks.unw.rsc Add_rmg.pl total_(date1)-(date2)_16rlks.unw.rsc.hst Add_rmg.pl 43

Appendix 6: What is the information in the RSC files? There are two basic kinds of.rsc files the majority are basically metadata files associated with binary file types and there is single a special file that has baseline parameters called (date1)- (date2)_baseline.rsc In this appendix, we briefly describe in words what each of these parameters are (unless they are self-evident). First, we describe the contents of an example baseline.rsc file, in this case an Envisat pair 071105_070827_baseline.rsc Parameter Value Meaning in words TIME_SPAN_YEAR -0.189767282683094 Fraction of a year spanned by interferogram H_BASELINE_TOP_HDR -63.8191108140557 Horizontal Baseline separation the top of the interferogram calculated from orbital parameters H_BASELINE_RATE_HDR -3.55838957699663e-05 Rate of change of horizontal baseline as a function of line number (linear term) H_BASELINE_ACC_HDR 6.48367839940016e-13 Acceleration in Rate of change of horizontal baseline as a function of line (quadratic term) V_BASELINE_TOP_HDR 53.2485631760515 Vertical baseline separation at top of the interferogram V_BASELINE_RATE_HDR -7.14349383113745e-06 Linear term for vertical baseline change V_BASELINE_ACC_HDR -5.11990142058556e-13 Quadratic term P_BASELINE_TOP_HDR 82.6737203821716 Perpendicular baseline at top of interferogram P_BASELINE_BOTTOM_HDR 90.1338698076062 44 Perpendicular baseline at bottom of interferogram ORB_SLC_AZ_OFFSET_HDR 946.529949909022 Predicted azimuth offset between scenes based on orbital information ORB_SLC_R_OFFSET_HDR 0.60979456590458 Predicted range offset based on orbital information RANGE_OFFSET_HDR 0 Default value PHASE_CONST_HDR -99999 Default value H_BASELINE_TOP_SIM -62.9293051978871 Re-estimated horizontal baseline H_BASELINE_RATE_SIM -3.572928016451527E-005 Re-estimated horizontal baseline rate H_BASELINE_ACC_SIM 1.727998572719075E-012 Re-estimated horizontal baseline acceleration V_BASELINE_TOP_SIM 54.2240296578691 Re-estimated vertical

baseline acceleration V_BASELINE_RATE_SIM -7.127750313278354E-006 Re-estimated vertical baseline acceleration V_BASELINE_ACC_SIM -5.856511379605454E-013 Re-estimated vertical baseline acceleration PHASE_CONST_SIM 291.369364741723 Phase constant to add to unwrapped interferogram based on baseline reestimation RANGE_OFFSET_SIM 0 Not used? Each.rsc file associated with a binary file has slightly different values within it. The following shows examples from the largest.rsc file generated from an ALOS pair 101018-080110-sim_SIM_4rlks.int.rsc Parameter Name Value Meaning WIDTH 2575 # of columns (remember actual width is 2x, see.rmg format information in Appendix 8) FILE_LENGTH 10857 # of rows XMIN 0 Minimum value of columns XMAX 2575 Maximum column value YMIN 0 Minimum row value YMAX 10857 Maximum row value RANGE_PIXEL_SIZE 18.737028625 Slant range pixel size (search for pixel_ratio to convert to ground size) AZIMUTH_PIXEL_SIZE 28.8062842440818 Azimuth pixel size at orbital altitude (multiply by re/(re+h) for ground size) RLOOKS 4 Number of range looks taken for this file ALOOKS 8 Number of azimuth looks taken (rlooks(pixel_ratio) DELTA_LINE_UTC 0.0038000002850000 # of seconds per line 2 BASELINE_SRC SIM Using re-estimated baselines HEADING_DEG -14.0398 Satellite flight direction in degrees relative to north RGE_REF1 863.4304 Distance to corner #1 from spacecraft (km) LOOK_REF1 32.4076 How accurate? Look angle at corner #1 LAT_REF1-42.5239 Latitude to corner #1 LON_REF1-71.9792 Longitude at corner #1 45

RGE_REF2 911.6782 Distance to corner #2 from spacecraft (km) LOOK_REF2 36.2743 How accurate? Look angle at corner #2 LAT_REF2-42.3085 Latitude to corner #2 LON_REF2-71.0914 Longitude at corner #2 RGE_REF3 863.4304 Distance to corner #3 from spacecraft (km) LOOK_REF3 32.5229 How accurate? Look angle at corner #3 LAT_REF3-40.0939 Latitude to corner #3 LON_REF3-72.9756 Longitude at corner #3 RGE_REF4 911.6782 Distance to corner #4 from spacecraft (km) LOOK_REF4 36.3731 How accurate? Look angle at corner #4 LAT_REF4-39.8862 Latitude to corner #4 LON_REF4-72.1192 Longitude at corner #4 STARTING_RANGE1 863430.4009085 Distance from satellite to first ground pixel (m) STARTING_RANGE 863430.4009085 Distance from satellite to first ground pixel (m) STARTING_RANGE2 863280.4009085 Distance from satellite to first ground pixel (m) FIRST_LINE_UTC 14990.683799929 Time at first line (seconds of day) CENTER_LINE_UTC 15011.3130514762 Time at middle of interferogram LAST_LINE_UTC 15031.9423030234 Time at bottom o interferogram SLC_RELATIVE_YMIN 26 DESKEW_FLAG 0 TIME_SPAN_YEAR -2.77190280629706 Fraction of a year spanned by interferogram ORBIT_NUMBER 25207-10445 Orbit numbers of (date1) and (date2) DATE12 DATE12 (date1)-(date1) 101018-080110 FIRST_FRAME 6330 Frame # of first scene FIRST_FRAME_SCENE_CENTER_TI 201010184951630 Time for ME FIRST_FRAME_SCENE_CENTER_LI 0 NE DATE 101018 Date of master scene FIRST_LINE_YEAR 2010 Year of master scene FIRST_LINE_MONTH_OF_YEAR 10 Month of master scene 46

FIRST_LINE_DAY_OF_MONTH 18 Day of month of master scene FIRST_CENTER_HOUR_OF_DAY 4 Hour of day of master scene FIRST_CENTER_MN_OF_HOUR 9 Minute of hour of master scene (first line) FIRST_CENTER_S_OF_MN 51 Second of minute of master scene FIRST_CENTER_MS_OF_S FIRST_CENTER_M S_OF_S 630 Millisecond of second of master scene PROCESSING_SYSTEM ALOS-DPS PROCESSING_VERSION 1.00 WAVELENGTH 0.236057 Radar wavelength PULSE_LENGTH 2.7e-05 CHIRP_SLOPE -518519000000 I_BIAS 63.5 Q_BIAS 63.5 PLATFORM ALOS BEAM 34.3 Mean incidence angle POLARIZATION HH RANGE_BIAS 0 PRF 2105.263 Pulse repetition frequency ANTENNA_SIDE -1 Right looking radar ANTENNA_LENGTH 8.9 Size of satellite antenna RANGE_SAMPLING_FREQUENCY 32000000 PLANET_GM 398600448073000 Planet mass time gravitational constant PLANET_SPINRATE 7.29211573052e-05 HEIGHT_TOP 712147.967096095 Height of satellite at first line HEIGHT 0.7121720763E+06 Height of satellite (m) HEIGHT_DT -27.9962745485104 Linear change in satellite height with line number VELOCITY 7580.57271854937 Spacecraft velocity LATITUDE -42.4431199 Peg point latitude LONGITUDE -77.8661704 Peg point longitude HEADING -13.8725327 Spacecraft heading at peg point EQUATORIAL_RADIUS 6378137 WGS-84 value ECCENTRICITY_SQUARED 0.0066943799901413 WGS-84 value 2 EARTH_EAST_RADIUS 6388319.94435277 EARTH_NORTH_RADIUS 6364465.24696199 EARTH_RADIUS 6365804.32893941 Best fitting spheroid radius ORBIT_DIRECTION ascending DOPPLER_AMBGTY 0 47

DOPPLER_RANGE0 0.0067213360900440 6 Doppler centroid (units are prf) DOPPLER_RANGE1 2.28561348621011e- 06 Doppler centroid linear variation with range DOPPLER_RANGE2-1.07191087634853e- Doppler centroid quadratic variation with range 10 DOPPLER_RANGE3 0 SQUINT 0.0253910708646971 Squint angle FILE_START 1 RAW_DATA_RANGE 865454 RANGE_OFFSET 0 HEIGHT_DS -0.3693181382E-02 The remaining values in the file all refer to the peg point are HEIGHT_DDS -0.4326548679E-10 CROSSTRACK_POS 0.1412487595E+03 CROSSTRACK_POS_DS 0.2012814739E-02 CROSSTRACK_POS_DDS 0.7129242974E-08 VELOCITY_S 7580.5306192 S, C, H are the coordinate system used in ROI_PAC (H = height, C= cross track, S= along-track) VELOCITY_C -0. -0.0000000 VELOCITY_H -25.2640572 ACCELERATION_S -0.0056200 ACCELERATION_C 0.7446846 ACCELERATION_H -8.1267189 VERT_VELOCITY -0.2518553212E+02 VERT_VELOCITY_DS -0.5471635058E-06 CROSSTRACK_VELOCITY -0.1538649914E+02 CROSSTRACK_VELOCITY_DS 0.1088296055E-03 ALONGTRACK_VELOCITY 0.7579872713E+04 ALONGTRACK_VELOCITY_DS 0.4632044475E-05 PEG_UTC 15011.307 Time when satellite at peg point 48

Appendix 7: Access to SAR data and special considerations for each satellite Available SAR satellite parameters Satellite repeat cycle (days) wave-length (cm) European ERS-1 1991-2001 ERS-2 (1995-2011) 35 (1,3,183 for certain months) 6 Canadian Radarsat-1 1995-present 24 6 European Envisat 2003-Sep.2010 (normal) special mode 2010-2012 35 (30 special) 6 Japanese ALOS Jan. 2006 Apr. 2011 46 24 German TerraSAR-X (2007-present), TanDEM-X (2010-present) 11 3 Italian COSMO-SkyMed 4x launch 07-10 16 (1,4,7,8) 3 Canadian Radarsat-2 (2007-present) 24 6 Japanese JERS-1 1992-1998) 44 24 NASA SIR-C (Space Shuttle 10 day 1 to 6 months 3, 6, 24 missions in Apr. & Oct. 1994) NASA Seasat (110 days in 1978) 17/3 24 Different acquisitions modes for each SAR satellite and ability to process with ROI_PAC Satellite Modes ROI_pac proc. ERS-1/ERS-2 1 strip map yes raw Radarsat-1 7 standard strip 5 fine strip ScanSAR strip: yes CEOS, soon STF ScanSAR: no Envisat 7 standard strip (IM) strip: yes raw ScanSAR (WS) ScanSAR: soon raw ALOS strip FBS, FBD, POL strip: yes raw TerraSAR-X COSMO/SkyMed ScanSAR strip ScanSAR Spotlight strip, ScanSAR, Spotlight ScanSAR: possible raw strip: SLC ScanSAR: maybe? Spotlight: soonish SLC strip: raw, SLC Spotlight: SLC Radarsat-2 strip (4 types), ScanSAR, Spotlight strip: SLC JERS-1 Strip Yes raw Seasat strip? SIR-C strip maybe 49

Data Access The following paragraphs describe practical ways to get SAR data from ERS, Envisat, JERS, Radarsat-1, TerraSAR-X, and ALOS PALSAR. To make a general comprehensive search for data (particularly from ERS and Envisat), we recommend the EOLISA (http://earth.esa.int/eoli/eoli.html) program from the European Space Agency which will run on Mac, Windows or LINUX. If you would like to get information on the Perpendicular Baseline between different image pairs, the best available resource is ESA's DESCW (http://earth.esa.int/descw/) program which only runs on Windows. You can supposedly get Baseline information on EOLISA, but I've never gotten this to work 100% of the time. For data archived at ASF (http://www.asfdaac.alaska.edu/), you can get Baseline info whenever you look at the results of a data search and a "Baseline Info" link appears to be clicked on. To gain access for ERS and Envisat ASAR data (either image or wide swath modes), you can write a ESA Cat-1 proposal (http://eopi.esa.int/esa/esa) to ESA. As of 2010, the data is now available at no cost. You need to describe your scientific objectives, how much data you need and of what type and ESA will review your proposal and give you an answer within a few months. For selected spots in the world, data from a variety of sources (including SAR, GPS, etc.) have been made available at no cost for the purpose of better understanding hazards. These spots are called supersites (http://supersites.unavco.org), and include major volcanoes (Hawaii, Mt. Etna), areas where recent earthquakes have occurred (for example, Haiti), and areas where future earthquakes will occur (for example, Tokyo, Los Angeles, Vancouver). Some data is available on the supersites for immediate download, while others requires you to obtain a password (http://supersites.unavco.org/apply.php). For U.S. based academic/research scientists (and potentially some others) There are 2 data archives available at each UNAVCO (http://www.unavco.org/) and ASF (http://www.asf.alaska.edu/) where you can get different types of data over different regions. WInSAR (http://winsar.unavco.org/) data is available to WInSAR members (academic and research institutions). Membership is free, but you need to apply (https://winsar.unavco.org/apply_im.html). Data in the WInSAR archive includes ERS, Envisat and a very little Radarsat-1 data, and maps of the geographic areas covered by the data are available here (http://facility.unavco.org/data/sar/status.html). note: to rename WINSAR data to ROI_PAC's convention, cd to the data directory and run "perl read_winsar.pl". Thanks to a new agreement with the German Space Agency (DLR), some TerraSAR-X data is now available in WInSAR. Please see the TSX page: http://aws.roipac.org/cgibin/moin.cgi/tsxfor more information about how to access this data and the restrictions. There are 17 Terabytes of data in the GeoEarthscope archive (http://facility.unavco.org/data/sar/collections.html#earthscope) from the ERS1, ERS2, Envisat, 50

and Radarsat-1. Access to data requires submission of a "mini-cat1" research proposal available here (http://facility.unavco.org/data/sar/apply.html#es) -- maps of geographic coverage are available here (http://facility.unavco.org/data/sar/status.html). Note: Much of the data requires being both gunzipped AND untarred, even though there is no.tar suffix. WInSAR members can get access to data from ALOS PALSAR by filling out this application (click on "new user") (https://ursa.asf.alaska.edu/cgi-bin/dua_form/guest/). In the comment field where it asks for a brief description of the purpose of data use, the member needs to enter the phrase "WInSAR". Once ASF receives the data use agreement, an account is set up with access to an archive of about >500,000 scenes mostly formatted at L1.0. You can search this archive here (https://ursa.asfdaac.alaska.edu/cgi-bin/geographic_search/guest/) -- it covers mostly the Americas, but limited data from other areas of the world are available too. If you aren't a WInSAR member, then join! (https://winsar.unavco.org/apply_im.html) Some data is available for immediate download from the ASF datapool. If the data you want is not in the datapool, but is from the Americas and you are a WInSAR member, you can request that data be transferred to the datapool by emailing ASF user services (uso-at-asf.alaska.edu). Data outside of the Americas not already in the datapool cannot be accessed from ASF. The complete ALOS catalog is available at the JAXA site (https://auig.eoc.jaxa.jp/auigs/top/top1000init.do). We recommend the use of the getsar tool (see below) if you are downloading lots of data. The ASF also has a large collection of SAR data from ERS, Radarsat-1 and JERS that they downloaded within the range of their satellite dish. Some Radarsat-1 data is available for areas all over the world -- you can search for the available data here (https://ursa.asfdaac.alaska.edu/cgi-bin/login/guest/) using the geographic search. Data products from the airborne UAVSAR project are available here (http://www.asf.alaska.edu/program/sdc/sensors#uavsar). Some of the ERS and Radarsat-1 data over the U.S. is in GeoEarthscope (http://facility.unavco.org/data/sar/collections.html#earthscope), but not all of it. To gain access to the data, you need to submit a short proposal (http://www.asf.alaska.edu/program/sdc/proposals) detailing the type of data you need and how much. Th proposal is usually approved within a few weeks. The JERS and ERS data from ASF have special formats that won't work in conventional ROI_PAC. A script to function for the ERS data is available here (http://www.geo.cornell.edu/eas/peopleplaces/faculty/matt/roi_pac.html/new_software_2.html), but the JERS data will not yet work. For use in ROI_PAC, the RADARSAT-1 data should be downloaded in CEOS format. University of Miami graduate student Scott Baker has written the getsar package for automated data download which he is making available to the InSAR community: http://www.rsmas.miami.edu/personal/mbaker/getsar.html (or google getsar). This package automates downloading data from the WInSAR archive and ASF L1 Data Pool, so you have to have accounts with those providers. There are 3 ways to gain access to TSX data. One way is to write a science data proposal (http://sss.terrasar-x.dlr.de/) to DLR and purchase the data directly from them. The data costs 200 euros per scene. 51

Another way is to register at the website (http://sss.terrasar-x.dlr.de/), and then write a proposal for no cost access to data from the DRA-2010 (Dual Receiver Antenna) campaign. More information about this campaign is available in this pdf (http://sss.terrasar-x.dlr.de/pdfs/tsx- DRA-2010-AO-1_0.pdf). WInSAR members have another way to access data, subject to the following rules from the data provider (DLR: the German Space Agency) A separate proposal is required for each and every research case (e.g Haiti earthquake). A license will be provided for each separate proposal. For each proposal one PI needs to act as responsible person. The PI can add further Co-Is at any time. Accordingly an update of both the signed user license and the proposal entries in the TerraSAR-X Science Service System is required. The TerraSAR-X data can be stored in the WInSAR archive for data sharing within the individual teams (proposal specific). A password-protected access is required (https://winsar.unavco.org/portal/). A re-use of those data for other research purposes is not possible. This requires a new proposal including a re-ordering from the DLR-archive. Metadata (date, track and frames of SAR acquisitions) are stored at WInSAR for the membership to know who has what data WinSAR researchers are encouraged to submit data proposals in order to acquire acquisitions. Background acquisitions can be long swaths and not only scenes. InSAR has been given a quota of 1000 scenes per year, and the WInSAR EC in cooperation with UNAVCO have prioritized these acquisitions to fit within the quota. PIs will not be required to pay for these acquisitions as long as data remain in the archive. If PIs request data, he/she will be charged with the standard 200 euros per scene. In 2014, WInSAR made a one-time purchase of some data. Special processing considerations for each data type: ERS: each frame in classic CEOS format has three files: data: IMAGERY1993011018252739T1Of3 leader: SARLEADER1993011018252739T1Of1 volume directory: VDF1993011018252739T1 make_raw.pl can concatenate many frames from a directory, uses IMAGERY* names to determine order New data downloaded from ESA comes as files DAT_01.001 (the IMAGERY file) and LEA_01.001 (the SARLEADER) file and so these files need to be renamed for make_raw.pl to understand what they are: for example, rename or link DAT_01.001 to IMAGERY00 and subsequent frames to IMAGERY02, etc. and LEA_01.001 to SARLEADER01. 52

Old versions of ROI_PAC had issues with making raw files larger than 2Gb or dealing with data downloaded from ASF (make_raw_asf.pl was required). Both of these have been fixed in more recent releases, so make sure you are using the most up-to-date software. ROI_pac can use three different orbit types for processing ERS-1 and ERS-2 data. 1. ERS data normally comes with orbit data in the file headers, which can be used to process the data with OrbitType=HDR. 2. Precise ERS-1 and ERS-2 orbits (called PRC orbits) can be obtained from ESA. Contact the ESA Earth Observation Help Desk [eohelp@esa.int] to get the download information. Select OrbitType=PRC to process with these orbits. 3. The Delft University of Technology used to calculate precise orbits for ERS-1 and ERS-2 called the ODR orbits. You have to install the "getorb" program from them to use these with ROI_pac http://www.deos.tudelft.nl/ers/precorbs/tools/getorb/. Select OrbitType=ODR to process with these orbits. ERS data has been produced in several different formats. The original ERS CEOS format was originally distributed on tape or CD-ROM. This is now distributed by WInSAR and other organizations as archives compressed with zip or other programs. In recent years, there have been a number of other formats with more info below. Noel Gourmelen similarly reports receiving files from ESA with naming similar to: ER02_SAR_RAW_0P_20020111T184028_20020111T184044_ESR_035180.CEOS Which were actually tar files containing CEOS format LEA, DAT,... files, but didn't have the ".tar" suffix. GeoEarthScope SuperCEOS format Some of the GeoEarthScope data came from ESA in the "new CEOS" format and some came from ASF in STF (Sky Telemetry Format), mostly within the ASF receiving station mask. Only the latter requires use of the SuperCEOS converter to get CEOS format files. The SuperCEOS format data should work with the standard make_raw.pl in ROI_pac except that it might require a small modification to allow a different "facility" name. Since about early 2008 (?), ESA has been offering two product formats for ERS data. One is a CEOS format, with a DAT file and a LEA file (plus a couple others) that is similar to what they have been using for a long time. This is usually delivered in a tar archive (see above). The second format is a single raw data and header file that is similar to the format of Envisat ASAR data. I have not seen one of the "Envisat-type" ERS files, but I understand they have filenames similar to the Envisat names, except that they start with "SAR_IM_0P" and end in ".E2" (for ERS2) instead of ".N1" (for Envisat 1). The ROI_pac releases up to 3.0.1 can only handle the CEOS format. The ESA Envisat-type format document is here (http://earth.esa.int/object/doc.cfm?fobjectid=5093). 53

Marie-Pierre Doin has modified the programs to read the "Envisat-type" format ERS data. There is a new program new_parse_ers.c: http://aws.roipac.org/cgibin/moin.cgi/ers?action=attachfile&do=get&target=new_parse_ers.c and Perl script: http://aws.roipac.org/cgibin/moin.cgi/ers?action=attachfile&do=get&target=make_raw_ers.pl uploaded here. Note that the Envisat-like format does not include a full set of state vectors, so it is not possible to use the HDR orbit option with this data. You will need to get the ODR or PRC orbits. This new code is "beta" so please let us know if you make further improvements. ERS-2 data after January, 2001 Zero Gyro Mode (ZGM) Only ~20% of the data acquired after January, 2001 is interferometrically pairable with the data before this date. But additional pairs above this ~20% number can be made between images acquired after January, 2001. The default value of DOPPLER_RANGE0 in the.raw.rsc is especially unreliable after January, 2001 so see troubleshooting problem #6 in Appendix 8 for information on how to change the file to try a different value that might be successful. In our experience, if the absolute value of DOPPLER_RANGE1 in a scene acquired after Jan. 2001 is greater than 10-4, the scenes is unlikely to pair with a date from before Jan. 2001, although it may pair with another date after Jan. 2001. Envisat: each frame or pass has one file: ASA_IM 0CNPDE20040623_031040_000000752028_00018_12096_0013.N1 (ESA name) [this name includes date, time, length in seconds, track and orbit] or ENV1_4_442_2871_2889_18031.baq (WInSAR name) [this name includes beam, track number, start/end frame, orbit number] make_raw_envi.pl can concatenate many frames from a directory, uses ASA* or ENV* names to determine order use DOR ( ESA DORIS) or ODR (Delft) orbits in make_raw_envi.pl, then use OrbitType=HDR in processing Envisat processing ROI_pac can process image mode (IM) (also called stripmap) raw (or Level 0) data from the ASAR instrument on Envisat. The distributed ROI_pac is not presently capable of processing the Alternating Polarization (AP) or Wide Swath (WS) modes, although there is an effort to develop a ScanSAR interferometry processor for the Envisat WS data and an alternative technique is described below. ROI_pac is not designed to process the SLC (Level 1) data products from Envisat, but a very preliminary package for importing SLC products into ROI_pac is available on the http://aws.roipac.org/cgi-bin/moin.cgi/contribsoftware page. 54

Envisat ASAR Level 0 (raw) data is a single file (the standard ESA name for the stripmap data is in the form ASA_IM 0*.N1 or if you get data from WInSAR it will have the form ENV1*.baq) so you can just copy this to your computer. The make_raw_envi.pl script is now included in the ROI_pac version 3.0.x releases, along with a program asa_im_decode written by SeanBuckley that actually reads the Envisat IM data. The script can use either the orbits from ESA (called the Doris orbits) or the Delft (ODR) orbits for Envisat. Note that the script extracts the orbit information from the ODR, POR or VOR orbits and stores them in a hdr_$date.rsc file with the raw data. For the rest of ROI_pac processing, you use $orbit_type=hdr. This script can concatenate or merge multiple scenes. To use the ESA Doris orbits (contact the ESA Help Desk EOHelp@esa.int for information on where to get these) you need to set the environment variables POR_DIR and VOR_DIR to point to directories of the POR (preliminary orbits) and VOR (precise orbits), and give the DOR parameter to the make_raw_envi.pl call. The ESA Doris POR orbits are usually available within about three days after acquisition and the VOR orbits are available about six weeks after acquisition. The ROI_pac software will first look for a VOR orbit for the desired date, and if there is no VOR orbit then it looks for a POR orbit. In addition to the data file and the orbit files, you also need to have the set of Envisat instrument calibration (INS) files on your computer. Create a INS directory and download all of the ASA_INS* files from http://earth.eo.esa.int/services/auxiliary_data/asar/current/ into the directory. Note that the INS files for older data (pre 2007) may be compressed, so you will have to gunzip or unzip them if they are. Then set the environment variable INS_DIR to point to that directory. The make_raw_envi.pl script will determine which of the INS files to use. Note that you need to update the INS files every year or when there is a change in the calibration of the Envisat ASAR instrument. Another script make_raw_envi_subset.pl and associated programs are not part of the 3.0 release but here under http://aws.roipac.org/cgi-bin/moin.cgi/contribsoftware. This script is for extracting a subset of a long "floating pass" product of ASAR Level 0 data. Envisat ScanSAR A new set of code has been contributed by CunrenLiang at Peking University to process Envisat WS data in ROI_pac using the zero-pulse padding technique, see the http://aws.roipac.org/cgi-bin/moin.cgi/contribsoftware page to download it, and the Envisat SCANSAR page for more details (http://aws.roipac.org/cgi-bin/moin.cgi/envisat). Envisat drifting phase At the end of October 2010, the orbit of the Envisat satellite was lowered by 17 km, putting it into a new "drifting phase" or "Extended Mission" orbit with a 30-day repeat cycle. In this new orbit, they will not be doing any orbit adjustments so the satellite will start to drift. At the ESA Living Planet Symposium of June-July 2010, they announced that they had modified the 55

plan for the "drifting phase" orbit of Envisat to have the "fixed nodes" of the orbit at 38 degrees N on the descending tracks and 38 degrees S on the ascending tracks instead of the previous plan to have them both at the equator. This means that we should get good baselines within about 4-6 degrees of latitude from those two fixed nodes. At other locations, the baselines will increase rapidly with time but 30-day or 60-day interferograms will probably be OK. Envisat is now in the new orbit and functioned completely from November 2010 to April 2012. ESA was accepting new acquisition requests. Of course, all of the new "drifting phase" tracks are completely different and can't be used with any old data from the original phase. It is like starting a new mission. Unfortunately, ESA lost contact with Envisat on 8 April 2012. There is no change to ROI_pac required to process the new Envisat data. Two Envisat "Extended Mission" or "2010+" orbit interferograms have been processed with ROI_pac, see http://www-radar.jpl.nasa.gov/crustaldef/san_fran. For more information about the Envisat Orbital Change (effective 22 October 2010): ESA Technical Document (http://earth.esa.int/download/envisat/impact-of-envisat- Mission-Ext-SAR-data-aug10.pdf) ALOS: each frame format has three files (make sure you have raw 1.0 data): data: IMG-HH-ALPSRP111820640-H1.0 A [name includes polarization (HH), orbit#, frame# and processing level (must be 1.0)] leader: LED-ALPSRP111820640-H1.0 A volume directory (not used): VOL-ALPSRP111820640-H1.0 A make_raw_alos.pl can concatenate many frames from a directory, uses IMG* names to determine order Code to read ALOS PALSAR data from the CEOS format used by ASF and JAXA into ROI_pac has been released. This software works on both FBS (fine beam singlepolarization), FBD (fine beam dual-polarization) and PLR (polarimetric) raw data (Level 1.0) PALSAR products. Use of Wide Beam (SCANSAR) PALSAR data is not currently supported in ROI_PAC, but is by another open-source InSAR processing package GMTSAR (http://topex.ucsd.edu/gmtsar/). David Sandwell and Rob Mellors have written four programs (ALOS_pre_proc, ALOS_baseline, ALOS_merge, and ALOS_fdb2fbs) for handling raw data format (Level 1.0 products) of ALOS PALSAR. This code is used to preprocess ALOS PALSAR data in L1.0 format in the GMTSAR (http://topex.ucsd.edu/gmtsar/) package but can also be used to ingest the data into ROI_pac. It has been tested with both FBS and FBD mode data at a variety of look angles. Note: the code was written for another processing system and generates an alternate type of ascii parameter files (*.PRM) which differ from the header files that roipac uses (The various *.pl scripts should handle the conversion). The main functions of the code are: 56

1) ALOS_pre_process - Takes the raw ALOS PALSAR data and aligns the data in the near range. In addition it produces a parameter files in the SIOSAR format containing the essential information needed to focus the data as Single Look Complex (SLC)images. 2) ALOS_baseline - Takes two parameter files of an interferometric pair and calculates the approximate shift parameters needed to align the two images as well as the accurate interferometric baseline at the beginning and end of the frame. 3) ALOS_merge - Appends two raw image files and eliminates duplicate lines. In addition it makes a new PRM file representing the new longer frame. 4) ALOS_fbd2fbs - Converts a raw image file from FBD mode (14 MHz) to an FBS mode spacing (28 MHz) by Fourier transformation of each row of the image file (one echo) and padding the spectrum with zeros in the wavenumber domain. A new parameter file is created to reflect the new data spacing and chirp parameters. A complementary ALOS_fbs2fbd program is also available but not automatically compiled with the makefile. The interferograms made from the FBD2FBS conversion have lower noise than the interferograms made from the FBS2FBD conversion. Their package is available on the http://aws.roipac.org/cgi-bin/moin.cgi/contribsoftware page here at roipac.org and at Rob Mellor s website (http://wwwrohan.sdsu.edu/~rmellors/rjm_insar_software.html) (new version Sept. 2009 now handles ScanSAR PALSAR (WB1) mode by adding zero pulses between bursts): http://www-rohan.sdsu.edu/~rmellors/alos_preproc.tar.gz Note that this software is not part of ROI_pac and has a different software license, so you need to download and compile it separately. The ALOS_pre_process and other executables should be installed in a directory (e.g., MY_BIN) and the MY_BIN environment variable must be set to the location of the directory with the executables. The make_raw_alos.pl script in ROI_pac will use $MY_BIN to find the programs. The Aug. 2008 version now works correctly with polarimetric (PLR) or quad-polarization PALSAR data at Rob Mellors web site: http://www-rohan.sdsu.edu/~rmellors/ Important Note! This ALOS package uses the environment variable $MY_BIN, which ROI_PAC doesn't necessarily need. Be sure to add the following line to SAR_CONFIG and source it before processing any raw ALOS data: % export MY_BIN=$INT_BIN An older version of make_raw_alos.pl was included in the ROI_pac version 3.0 and 3.0.1 releases. That script requires the ALOS_pre_process described above as that is not included in the ROI_pac release. The $MY_BIN environment variable must be set to the directory containing the ALOS_pre_process executable to use this script. Note that you should only give the first part of the ALOS IMG filename as the script parameter. The 57

script will search for all files with that start to the name and ending in the -H1.0_A or - H1.0_D suffix. A new make_raw_alos.pl (http://aws.roipac.org/cgibin/moin.cgi/alos_palsar?action=attachfile&do=get&target=make_raw_alos.pl) script has been uploaded here. This version can not only merge a set of ALOS frames, but also perform conversions between FBD and FBS images (Zhenhong Li, 19 Oct 2007). This version can be substituted for the make_raw_alos.pl in ROI_pac version 3.0 with the same requirement that $MY_BIN environment variable must be set to the directory containing the ALOS_pre_process executable (and also the optional ALOS_merge and ALOS_fbd2fbs executables) to use this script. Note: you may need to run dos2unix on this Perl script depending on how your browser downloads it. ERSDAC format ALOS PALSAR data from the Japanese ERSDAC has a different format from the data that is produced by the JAXA software used at the AUIG data node, ASF AADN and ESA ADEN. It is a type of CEOS format, but the files are organized differently, and the orbit data is provided in inertial coordinates instead of the Earth-fixed coordinates that ROI_pac requires. David Sandwell has a new version of ALOS_pre_process that can handle the ERSDAC format and do the coordinate transformation available http://topex.ucsd.edu/gmtsar/tar/alos_preproc_ersdac_auig.1.2.tar Yuri Fialko and Rob Mellors have written make_raw_alos_ersdac.pl that is uploaded here: http://aws.roipac.org/cgibin/moin.cgi/alos_palsar?action=attachfile&do=get&target=make_raw_alos_ers DAC.pl processing issues with PALSAR The ALOS PALSAR system often updates the pulse repetition frequency (PRF) of the SAR acquisitions. This means that many PALSAR pairs have different PRF values for the two scenes. In ROI_pac release 3.0, we have attempted to avoid problems with the initial matching of the two scenes with offset.pl by using a large search distance. This works for scenes where the PRF differs by a small amount (about 0.1 to 0.5% difference), but it may not work for larger differences. (EJF 2007/12/4) ROI_pac release 3.0.1 includes a modification that uses a scaling factor in the azimuth and range offsets that greatly improves the matching for pairs with PRF differences and with long baselines. We have not yet solved the problem if the PRF changes in the middle of the scene. For now, we recommend processing one pair of images for the scenes before the PRF changes and another pair after the PRF changes to produce two separate interferograms and directories. 58

TSX: unpack TSX product (e.g., Sendai_D_Orbit042_20110608.tar.gz from Supersite or dims_op_oc_dfd2_339154502_1.tar.gz from DLR) TSX product directory (e.g., dims_op_oc_dfd2_339154502_1) contains many subdirectories and files go to scene directory (e.g., 110608) run make_slc_tsx.csh on.xml file of TSX product e.g.: $TSX_DIR/make_slc_tsx.csh../dims_op_oc_dfd2_339154502_1/TSX- 1.SAR.L1B/TSX1_SAR SSC SM_S_SRA_20110608T204311_2011060 8T204319/TSX1_SAR SSC SM_S_SRA_20110608T204311_20110608 T204319.xml 110608 TerraSAR-X (TSX) is an X-band satellite launched by the German Space Agency (DLR). The DLR also launched a second nearly identical satellite called TanDEM-X (TDX) into the same orbit as TSX. The two satellites are now flying in formation separated by a few hundred meters and they are starting to use the two satellites to acquire bi-static InSAR data where one satellite transmits and both receive the data to obtain simultaneous SAR images with a moderate baseline for topographic mapping (similar to SRTM). The two satellites are also being used to acquire the regular mono-static or single-satellite images. Processing TSX data The DLR (and commercial data provider Infoterra) only provide TSX and TDX data as SLC or multi-looked products. They do not distribute raw data. The DLR provides the SLC images in a format called COSAR (see http://aws.roipac.org/cgibin/moin.cgi/raw_formats) page for more details). An open source (GPL v2) license program called "cosar" has been uploaded http://aws.roipac.org/cgibin/moin.cgi/tsx?action=attachfile&do=get&target=cosar-1.0.tar.gz) that can read the cosar format and write out a plain binary image. Scripts for ingesting TSX and TDX mono-static data acquired in Stripmap mode into ROI_PAC (including the cosar program) posted http://aws.roipac.org/cgibin/moin.cgi/tsx?action=attachfile&do=get&target=tsx-dir.tar.gz). The "make_tsx_slc.csh" script calls other scripts and programs to convert the TSX data to a {$date.slc} image file with associated {$date.slc.rsc} metadata. Note that a number of other changes to the ROI_pac "process_2pass.pl" and other scripts and programs may be necessary to process TSX data because processing has to start from SLCs and TSX SLC images are typically wider than other SAR images. These changes will be included in the ROI_pac v3.1 release soon. RADARSAT-1 Radarsat-1 standard and Fine Beam data from ASF in CEOS format can now be processed in ROI_PAC. Download a tarred set of scripts, source code to compile, and instructions (README file) at: http://www.geo.cornell.edu/eas/peopleplaces/faculty/matt/roi_pac4radarsat.tar 59

Note that this code comes in two versions, one for big-endian computers and one for little-endian computers. We are waiting for a volunteer to merge the two into source code that works on both computer types before incorporating it into ROI_pac. This is an updated version of what is on the WInSAR site. These codes produced results published in Pritchard & Simons, 2004 and Pritchard et al., 2007. Things to check if something goes wrong: Doppler ambiguity: Sometimes guesses wrong integer. If image looks "fuzzy" (especially in urban areas) try another integer by editing the date.raw.rsc file before running the rest of ROI_PAC. Most of the New Orleans standard beam Radarsat data, for instance, appears to be on the -4 ambiguity, while the fine beam is on ambiguity +8. The program has worked successfully on standard and fine beam scenes. In our experience, the doppler ambiguity for the fine beam is usually an integer value lower than that determined by the software. This was determined because the azimuth offset between 2 images sometimes had a quadratic shape as a function of range when the wrong ambiguity was used. DWP: This file is made by make_raw and ends.dwpf and the format is simple: line # (space) horizontal shift. If your image is coherent and then is abruptly not, or if you see a sort of "double image" this is a likely problem. You can use the ampcor offset field to determine the magnitude and approximate location of the needed shift, but some pairwise logic will be required to determine which scenes are bad. RADARSAT-2 Software to process Radarsat-2 data is still under development JERS-1 JERS is fully functional with the current ROI_PAC release, with results using this software published in Whelley et al., 2012; Pritchard et al., 2007 and Wdowinski et al., 2004. But be warned: the data processing is not as smooth as with ERS. In particular, the orbital information (see below) is of lower quality, and the Doppler is not always correctly estimated. Also, joining several scenes together is not always seamless -- if you are having problems, fiddle with the offset in date.raw.dwpf. To process the data, there are some differences with ERS data, such as the following: - In the directory with the raw data (here called./date) place a file called date.proc with the following line: valid_samples=1200 - instead of make_raw.pl run par_make_raw_jers.pl (remember that the only orbital information is HDR, so there will likely be residual ramps in the data). - instead of process_2pass.pl run process_2pass_jers.plbut some special steps are required (see FAQ that is part of the package). In particular, the.dwpf file may need to be 60

SEASAT: modified by hand, and the doppler ambiguity may need to be manually set (near 1 seems to almost always work). Seasat was a satellite launched by NASA in 1978 that carried an L-band SAR. One of the first demonstrations of repeat-pass InSAR was done with Seasat data, using programs that were early precursors of the programs in ROI_pac. (Gabriel et al., 1989) Seasat SAR was recorded in "offset video" encoding, not the I, Q encoding used on all the present SAR satellites. ROI_pac can process the offset video data by just setting the "Flip I, Q" parameter of the "roi" input file to the letter "o". 61

Appendix 8: Viewing ROI_PAC output files and moving them to other programs Viewing Results There are several ways to display ROI_pac processing results. If you want more information on the file formats used so that you can load the results into your own favorite analysis tool such as Matlab, see the ROI_pac Internals document on the http://aws.roipac.org/cgibin/moin.cgi/shortcourse page. Contents 1. MDX 2. Viewing output with ArcGIS or ArcMap 3. Viewing output in IDL 4. RoiView Two programs have been developed by Scott Shaffer at JPL/Caltech for viewing SAR images, interferograms and other imagery on X Window System displays. There are Perl scripts included with ROI_pac (dgx.pl and mdx.pl) that will automatically run DGX and MDX, respectively, with the proper parameters to display the ROI_pac results. The newer program MDX, which works on modern 24-bit displays with the X Window System (a.k.a X11), is available for licensing from JPL. MDX is now distributed at UNAVCO (http://winsar.unavco.org/isce.html) with the ISCE software license through UNAVCO for WInSAR members (remember it is free to join: https://winsar.unavco.org/apply_im.html) The old MDX license procedure is to access http://download.jpl.nasa.gov, select "Request Software" and follow the instructions provided. NOTE: You must be a "professor or higher" permanent to complete a successful application -- students or other "individuals" will not be approved for use of this software. The "designated signatory" needs to be either the head of a department or someone from who can legally bind the organization to the terms of the license. It typically takes several weeks to months to receive a response from JPL to your application, especially for institutions outside of the USA. Once the JPL Software Release office has the signed license forms, they can give a user name and password to download MDX. The MDX license, like ROI_pac, is free for non-commercial purposes. Another option is to convert the ROI_pac files to "flat" binary files and load them into GMT or other visualization software. A rmg2grd.pl script that converts files to GMT is available on the http://aws.roipac.org/cgi-bin/moin.cgi/contribsoftware page. The older program DGX, which only works on certain older computer systems with 8-bit color displays, is available from Open Channel Foundation (http://www.openchannelfoundation.org/projects/dgx) 1.0 MDX Some basic mdx commands: 62

Intro: MDX is ideal for reading the various ROI_pac file formats. ROI_pac includes a Perl script "mdx.pl" that can run MDX to view ROI_pac output files. The "mdx.pl" script automatically reads the extension at the end of the file (*.slc, *.unw, *.dem, *.hgt, *.cor, *.msk, *.int) to figure out the file format, and reads the.rsc file for the information on the number of rows and columns. Remember that many of the files follow the Richard M. Goldstein (RMG) format (-rmg option) (real*4: including.unw,.hgt,.msk and.cor): each line has twice the number of columns specified. For each line, first there is a column width of "amplitude" values, then a column's width of "phase" values. The other common types of file formats are integer*2 (- i2 option) (.dem) and complex*8 (-c8 option) (.slc and.int). The "mdx.pl" script should add the correct option for you. For example: mdx.pl geo_20100502-20100606_4rlks.unw will read the geo_20100502-20100606_4rlks.unw.rsc file to determine the width and it will determine that the file is an RMG file from the ".unw" suffix (adding the -rmg option). It will display the amplitude and phase with a default color wrap of 6.28. Basic features: For all files except.dem there should be two buttons in the lower left: an "amplitude" button and a "phase" button. If you left click on one or the other it should show that component of the file you are looking at. If you'd like to see both phase and amplitude simultaneously, left click on one of the buttons then center click on the other. If you left click on a given pixel, the COL (column) and ROW value of that pixel will appear immediately above the image as well as the amplitude and phase values of that pixel. If you'd like to change the stretch on the amplitude or the wrap rate on the phase right click on the "amplitude" or "phase" buttons, and then use the scroll down menus and type in the values that you'd like. For example, we often need to change the wrap rate to 6.28 radians. To do this we right click on "phase", find "WRAP" in the scroll menu then type "6.28" next to the word "Wrap:" Sometimes the amplitude image might appear washed out. It sometimes helps to right click on "amplitude" and select SDEV from the pull down menu. You can also use the "right click" menu to change the color table on the last line of the pop-up window. Common choices are cmy and grey. Most of the pop-up window settings can be specified from the command line when you summon mdx. To get a full list of the options, just type mdx. For example, I often type mdx.pl filename - le (or -be) to view a file that is little endian or big endian. To create a colorbar, move the mouse over the "Mag" or "Phs" button and press the shift and left mouse button keys simultaneously. You need the xmgrace package for this to work. An easy way to download this package on a Mac is with the MacPorts (http://www.macports.org) program. There are a series of menus across the top of the viewer that will allow you to zoom in and zoom out, print to a file or perform other commands. You can also execute these commands with key strokes as long as you type the key strokes while the cursor is over the active image area. 63

Known issues: If you want to view a file with more than 30,000 lines you will first have to zoom out and then zoom in to your region of interest. There is currently no functionality to flip an image left to right like there was in the old DGX. This was useful for descending images which look backwards (if we consider north to be up in the image). Viewing output with ArcGIS or ArcMap First step is to use the ROI_pac function rmg2mag_phs which separates the bands into two floating point grids (.mag and.phs). Make a copy of these files and rename the grids with the extension.flt. Then you must create a.hdr file from the.unw.rsc (ascii file) that looks like this... NCOLS 990 NROWS 1110 XLLCORNER -72.9995833333334 YLLCORNER 17.9995833 CELLSIZE 0.00083333333333 BYTEORDER LSBFIRST Because ArcGIS uses the lower left (LL) corner, use the X_FIRST for the XLLCORNER. For the YLLCORNER you must take the Y_FIRST + (Y_STEP*YMAX). Finally, perform the "floatgrid" command(arcinfo)/tool(toolbox). 2.0 Viewing output in IDL The IDL procedure read_roipac.pro (available on the http://aws.roipac.org/cgibin/moin.cgi/contribsoftware page) reads automatically common ROI_pac data files. The result image is in BIP order (band interleaved by pixel) for easier visualization, e.g. with the procedure mtv.pro. For example, to read and show the interferogram and elevation images one would write: read_roipac, insar_dir+'930110-950523.int', img mtv, img, /ka, /i ;; show intensity image (/i for intensity, /ka for keep aspect ratio, ;; but reduced window size; or use /orig for original image size) mtv, img, /ka, /p ;; show interferometric phase (/p for phase) read_roipac, insar_dir+'sim_4rlks.hgt', img mtv, img, ch=0, /o, /m ;; show amplitude (ch: channel to show, ;; /m for magnitude, /o for original/full image size) mtv, img, ch=1, /o, /cont ;; show elevation (/cont for show contours) Alternatively, if one only wants to see the result, one can call read_roipac with the /SHOW keyword (needs mtv.pro to be reachable by idl), which will then visualize the data automatically. The "img" parameter for the data is then optional. More mtv keywords can be given, which will be forwarded by read_roipac. For the two examples above the code would be: 64

read_roipac, insar_dir+'930110-950523.int', /SHOW read_roipac, insar_dir+'sim_4rlks.hgt', /SHOW, /o For more information, see the source files. 3.0 RoiView Another option is the RoiView http://roiview.sourceforge.net/package from Ran Novitsky Nof. This is built upon Python. See http://rnovitsky.blogspot.com/search/label/roiview for more info and downloading instructions. 4.0 Preparing data for modeling In order to do quantitative modeling of the output of ROI_PAC, you will probably want to load the derived products into other programs. Below are some hints and software that will help you do this. GOOGLE EARTH Perl scripts: unw2png.pl and importimgtokml.pl will convert a geocoded interferogram to a Google Earth kml file and png file Download the scripts here. http://aws.roipac.org/cgibin/moin.cgi/modeling?action=attachfile&do=get&target=for_google_earth.tarthis code requires that you have imagemagick (http://www.imagemagick.org/) installed. It's free and the "convert" command line utility is fantastically useful. This code also requires mdx (see the beginning of this appendix). GMT Various GMT scripts are available in the http://aws.roipac.org/cgibin/moin.cgi/contribsoftware section, particularly roipac2grdfile MATLAB Example Matlab script for loading data in a variety of formats. Available in the http://aws.roipac.org/cgi-bin/moin.cgi/contribsoftware section GIS For GIS software, use.rsc file to create metadata file and perhaps rmg2mag_phs to make a single binary file from the Richard M. Goldstein (rmg) format (real*4: including.unw,.hgt,.msk and.cor): each line has twice the number of columns specified. For each line, first there is a column width of "amplitude" values, then a column's width of "phase" values. MAKE_LOS There is a script in ROI_PAC called make_los.pl that will generate a file that gives the incidence angle (the magnitude portion of the rmg file) and satellite heading (the phase portion) for each pixel. This information is essential for use in converted modeled ground displacements in x, y, and z to the projection in the satellite LOS. Run "make_los.pl" on the int.proc (http://aws.roipac.org/cgibin/moin.cgi/roi_pacparameterfile) file used to process the interferogram (e.g., make_los.pl int.proc). This may require adding the full file paths to all of the directories specified in the "int.proc" file. 65

VARRESPY: Variable Resolution Sampler attempts to reduce the redundancy in an unwrapped interferogram by identifying data samples that sufficiently represent the change in curvature of the surface deformation signal. This code implements the variable resolution resampler originally developed by Simons et al (2001) in Numpy/Scipy and includes some new extensions like an approximate covariance model. Package can be downloaded from GoogleCode (http://code.google.com/p/varrespy). 66

Appendix 9: ROI_PAC Troubleshooting In this section, we provide a description of several different problems that you might encounter that are due to problems with installation, issues with data from certain satellites, or quirks of the software. We list them in the approximate order that new users seem to experience them, but your mileage may vary. As always, visit roipac.org for the most up-to-date information on software patches and solutions. 1. Issues with incomplete installation Please see http://aws.roipac.org/cgi-bin/moin.cgi/askquestionor http://aws.roipac.org/cgi-bin/moin.cgi/faqfor the most common problems with compilers Error: command not found Make sure all paths in SAR_CONFIG are correct 2. Too few points left after culling or problem with co-registration or offsets This is by far the most common problem once you have the software installed. It can happen at 2 stages in the processing: I) when co-registering the slcs s to each other or II) when coregistering the DEM to the interferogram. We will address them in turn. I) slc co-registration problem: error message: +process_2pass.pl raw2ampintcor.pl failed in process_2pass.pl This is a result of a large offset between the two radar images, and the ampcor script cannot match the two slcs. To fix this, you'll need to open both slcs, find the pixel offset, and input this into the ampcor.in file. Here is the recipe: 1. open DATE1_16lks.slc and DATE2_16lks.slc in int_date1_date2 folder using mdx. If SLC files are blurry, unfocused, or you see multiple images of the same topographic features, you have a different problem see Troubleshooting #X) 2. find common pixel in both images to determine pixel offset 3. By default, the slc images have an azimuth resolution 5 times higher than the range resolution (horizontal). (The multiplicative factor is set in the *.proc file by the pixel_ratio command.) For Azimuth offsets multiply pixel offset by 80 (if viewing the _16lks.slc) For Range offsets, multiply pixel offset by 16, edit DATE1_DATE2_ampcor.in file to adjust this offset distance. If the file DATE1_DATE2_ampcor.in doesn't exist, use the DATE1_DATE2_ampcor_gross.in file and see step #6 below. 67

a. if offset is negative, edit starting line to make sure program won't try to access lines that don't exist b. try increasing search window size from 64 x 64 pixels to 128 x 128 c. increase the pixel sampling resolution in ampcor.in ( decrease the last value in samples/lines) 4. run ampcor (ampcor DATE1-DATE2_ampcor.in rd. > out) 5. run fitoff on output of ampcor (fitoff DATE1-DATE2_ampcor.off DATE1_DATE2_cull.off 1.5.1 10) If you edited DATE1_DATE2_ampcor_gross.in the file DATE1_DATE2_ampcor_gross.off will exist instead of DATE1- DATE2_ampcor.off. But the Fitoff command is the same. Make sure that the fitoff command runs successfully to completion by outputing a bunch of fit parameters to screen -- if only one or two lines of text are output to screen the process did not work and needs to be run again. 6. If file DATE1_DATE2_ampcor.in doesn't exist, you will need to create a file DATE1_DATE2_cull.off.rsc (in addition to the DATE1_DATE2_cull.off file you made in step #5). You can do this by copying DATE1_DATE2_cull_gross.off.rsc to DATE1_DATE2_cull.off.rsc 7. rerun processing from offsets to done_sim_removal (or wherever) II) processing stalls at +synth_offset.pl Culling points. Here is the recipe to fix this: 1. terminate process_2pass.pl 2. using mdx, open DATE1-DATE2_16rlks.cor and SIM_16rlks.hgt Does the.cor file look blurry? see troubleshooting issue #X. Does the.hgt have a lot of holes in it? see troubleshooting issue #X (Do not worry if the magnitude looks black but the phase looks ok) 3. find offset between two images (this can be tricky, If the magnitude is black, use the phase and try changing the wrap rate on the images to enhance details.) 4. edit ampmag.in file: 68

a.match REGION: b. if start line > end line, enter 1 or suitable starting location given negative offset c. if start sample > end sample, enter 1 suitable starting location given negative offset d.match PARAMETERS: edit mean offset according to offsets found above 5. run ampcor on ampmag.in (ampcor ampmag.in rdf > out) 6. run fitoff on ampmag.off First run: fitoff ampmag.off DATE1- DATE2_cull.off 1.5.1 10 Make sure the output to the screen shows a good fit (with many parameters) instead of failing by only outputing one to two lines of text. If successful, run fitoff a second time: fitoff ampmag.off DATE1-DATE2_cull.off 1.5.1 10 > cull.out 7. restart processing from done_sim_off (process_2pass.pl int_date1- DATE2.proc done_sim_off done_sim_removal) 3. Unwrapping: Is the *.unw file all zeroes or nearly so? This is a common issue, and requireds that a specialized strategy for unwrapping may be necessary with your data. This is both an art and a science, but here are some suggestions to try: a. Manually specify the starting point for the branch cut unwrapping algorithm. The default is to start in the center of the image, but this location might be noisy and if you start in another location the unwrapping might be completely successful. See Appendix 4 on user supplied input for the starting point for the unwrapping by defining the unw_seedx and unw_seedy values in the *.proc file. b. If the interferogram has large areas where the phase is not coherent with the branch cut algorithm, it often happens that only one patch of the interferogram around the starting point is unwrapped and disconnected coherent patches are not. ROI_PAC has the option of defining bridges between disconnected, coherent areas by setting a text file called bridge.in (see Appendix 9 on the bridge function for more details) c. Some other tricks to try with the branch cut algorithm (you can try one or all of these together): i. Filter the interferogram more (increase the $FilterStrength) ii. Look the interferogram down (increase $Rlooks_unw) iii. Use a different set of parameters when creating the.msk file (for example increase $sigma_threshold) d. Use a different unwrapper than the default branch cut algorithm: ROI_PAC supports the snaphu and icu unwrappers. The icu unwrapper is not fully supported (but it has the advantage of unwrapping in patches so can work well on large interferograms and also has guiding centers for branch cuts), but the snaphu unwrapper is a powerful tool that will unwrap the entire image. See 69

4. make_raw_(sat).pl terminates before completion (for ERS or Envisat) with an error message like orbit file does not exist or state_vector.pl failed. Solution: make sure that you have downloaded the orbit files for ERS and Envisat and that the path to these files is set correctly in the SAR_CONFIG file. If you have downloaded the files and the path is correct, maybe the orbit files don t exist? For example this is a problem with ERS1 in 1997. If the files do not exist, rerun make_raw using the orbit data from the Header files (HDR -- much less accurate but will still work sometimes). Follow these steps: 1. remove.rsc file 2. rerun using: make_raw.pl HDR SARLEADER DATE 3. change line in parameter (.proc) file from: OrbitType=ODR to OrbitType=HDR 5. When processing ALOS or TSX data, my DEM is full of holes (and probably fails). Solution: use a higher resolution DEM or modify Aik_resample.in to have a larger pad_size 6. SLC or interferogram amplitude is blurry or shows ghosting This is most likely the result of poor focusing of the SAR image, most likely due to an incorrect Doppler centroid. Look at the dop.out file under each date directory. If the values in the second column oscillate between positive and negative, then open the DATE.raw.rsc file for each date and look at the values for DOPPLER_RANGE0. If one date in the pair is positive and the other is negative, one must be changed so that both are either positive or negative. Change the value for DOPPLER_RANGE0 by either adding 1 if the value is negative or subtracting 1 if the value is positive. Delete the original slc files (rm *slc* *roi*) from each date directory. Delete the int_date1_date2 directory (rm -r int_date1_date2) Run process_2pass.pl from raw to done_sim_removal (process_2pass.pl int_date1_date2.proc raw done_sim_removal) 70

7. Does the interferogram looked stretched out but otherwise ok? You may need to reset the pixel_ratio value in the *.proc file (see Appendix 4 for how to calculate this value) 8. Is there a strip of coherence only in the center of the image? This may be caused by the offsets between the images having a quadratic instead of a linear variation. You may need a quadratic offset calculation available here: http://aws.roipac.org/cgibin/moin.cgi/contribsoftware - head-b2618a151443fc341503807862a852e5cee3d0fc 9. The interferogram is unwrapped and the baselines are re-estimated, but there are more fringes in the re-estimated interferogram than in the original. What happened here is that the baseline re-estimation went awry, possibly because of an a. unwrapping error. To diagnose this, use mdx to look at the *.unw that was created before the baseline re-estimation. Use different wrap rates to assess if there is an unwrapping error (see basic features of mdx in Appendix 8 for details on how to do this). b. there is a real signal in the interferogram (like the ionosphere or deformation) that the baseline re-estimation process is trying to remove. You can use a model to remove this signal before the baseline re-estimation (see radarseismodel.pl script information) c. Too few points were used in the baseline re-estimation. This could be a problem if your interferogram was small to begin with (a fraction of a normal ERS frame of 5000 x 10000 pixels) if this seems likely, make your interferogram larger by cropping it less severely or adding frames. Alternatively, maybe only a small fraction of your image unwrapped. If the problem is unwrapping, see troubleshooting step 3 for details on how to improve the unwrapping result. 10. Missing lines: In ERS data, why are there big black horizontal streaks [data voids]? Horizontal black streaks across the image indicate data voids that have been filled. With ERS data these voids might be real -- The way to check this is to see if the size of one of the raw data scenes in the pair is significantly smaller than normal (about 330 Mb). For Envisat the voids may also be a real gap between data acquisitions and these are normally visible when viewing the data availability in EOLISA. If the size is normal, the data voids are likely to be fakes -- the ROI_PAC software thinks the lines are missing, but they aren't. We have found "fake" missing lines in several areas (Socorro, New Mexico; Long Valley, California; Yucca Mountain, Nevada; and especially South America). We have written software to correct these fake missing lines, but the process can be rather labor intensive, and is not recommended for new ROI_PAC users. The recipe for doing this is below. Please let us know if you have any problems using the software. If 71

you are successful with the software and publish your results, please cite Pritchard et al., 2002; where we used the software to study the 1995 Antofagasta, Chile earthquake. Here is the recipe: Step 1: Download and modify the following software line # in IMAGERY file You need to download this tar file and edit the files in a few places (see the * below). To make these changes obvious, I've inserted the name "Fred" in the code where the changes need to be made -- so you can just search the codes for "Fred" to see what needs to be done. You will also need to compile the various programs. Step 2: Run make_linefix_raw.pl This program is like the usual make_raw, but instead of using the line counter to fix missing lines, it doesn't use the line counter at all and just outputs every line of raw data. This requires a modified version of new_parse.c, which is also attached. In addition, once you have made_raw you will run another program called first_pass.f I can usually tell which of the two scenes in a pair is the one with missing lines. I run the normal make_raw on the good scene and make_linefix_raw.pl on the bad scene. * You need to modify make_linefix_raw.pl to set the path to your local versions of new_parse * You need to insert the correct line width, $LineCounterFirstByte, file name and length into first_pass.f Step 3: Find missing lines There are a couple of ways of doing this, and you might need to use all of them to solve your problem. The basic strategy is to decide where there are missing lines or extra lines added and modify a lookup table to tell the program missing_line.f when to add or take away lines. * You need to insert the correct line width, file name and length into missing_line.f * You need to copy the file first.rep to iter.rep 1. the output of first_pass is a file called first.rep where the columns mean: #1 #2 #3 #4 #5 #6 #7 # of correlation missing line # in ERS clock clock flag with last lines from.raw file value (see below) line IMAGERY line counter 1 = add # of lines in #4; 0 = do nothing 72

make a copy of this file called iter.rep where you will actually make modifications to columns #4 and #7 to tell missing_line when to add or remove lines. [It is good to keep a copy of first.rep around, just in case.] A positive value in column 4 tells the program to add that number of lines and a negative value to remove them. Column 5 is just a logical value specifying whether the change in column 4 should be turned on or off. 2. As a first step to fixing missing lines, I have set the default of column 7 to be 1 if column 4 is nonzero. This is likely to be wrong in some places -- to find out where, here's what I do: * copy first.in to missing_line.in, You will need to insert a new 2nd line to the input file to specify the name of your iter.rep file *Run missing_line.f (just missing_line < missing_line.in), there should be an output file called lines_fixed.raw Make slcs using this file and the good file from the other date. Run ampcor to roughly pin down where the problem areas in your area are. There will be offsets in the azimuth offsets where the lines are missing. (To save time, I set the parameters in roi.proc to make very narrow slcs). I usually view the azimuth offsets in a program like matlab. 3. Deciding which lines are bad: Once you've looked at the azimuth offsets and roughly decided where there are missing lines (+/- several hundred lines) here's how to pin them down: Three ways: In some cases, all methods indicate a missing line. This usually means that there probably is one. Other times one method says there is a missing line but the other methods don't. I solve this usually by trial and error. Here are the 3 ways: 73

1. The line counter (we assume this is correct for the 1st iteration) 2. The line to line correction (column 3) Usually it should be around 0.3, if it is less than 1, there might be a missing line problem. I find those easily by searching the file for "E" as in 5.33332E-03, or 0.0 since most (but not all!) missing lines have correlation less than 0.1 3. Satellite clock. The time each line is collected is recorded. Unfortunately, the clock is not sufficiently precise and multiple lines have the same time. The clock value is recorded in column 5 of first.rep However, the binary nature of the clock helps: there should be either 4 or 8 lines with the same time. If there are not 4 or 8 lines with the same clock value, the clock_flag (column 6 in first.rep) is set to 9999. Before changing a line based on the clock flag alone, make sure to check the clock value on adjacent lines -- sometimes the clock seems to output an erroneous value. I usually rely on the clock only when the azimuth offsets indicate a missing line, and the correlation and line counter don't help me pin down exactly where it should be (which only happens rarely). 4. After modifying columns 4 and 7 in iter.rep to specify how many lines to add in various locations, I rerun missing_line.f and remake the slcs and look at the new azimuth offsets, and repeat this process until I converge on a solution. Step 4: Once lines are fixed, continue processing with process_2pass.pl 74

Appendix 10: What ROI_PAC can t do (yet) Work is continuing on incorporating the following capabilities into ROI_PAC (a partial list): 1) SCANSAR data from Envisat and ALOS. 2) SCANSAR-standard/fine beam combination 3) Multiple Aperature InSAR: Several different versions of the software exist but none are part of the ROI_PAC release. 1. Noa Bechor and Howard Zebker have a package for their MAI software (Bechor & Zebker, 2006) which includes a bug fix for the deskewing done by roi.f 2. Sylvain Barbot's software (published in Barbot et al., 2008) is available at: http://sylvain.barbot.free.fr/insar/index.html 3. Hyung-Sup Jung's software (Jung et al., 2009) has been used in several publications (Biggs et al., 2009; Lu and Dzurisin, 2010) and works with ALOS, RADARSAT, ERS,ENVISAT, and JERS-1, but does not work with ROI_PAC yet. 6) Non-affine resamp_roi (use the full offset field via rubber-sheeting like what the glacier folks use and Sang-Ho Yun did for the Galapagos) 7) Use DEM during co-registration process (This has perhaps been implemented in GMTSAT) 8) have the pixel_ratio value automatically set depending on the type of satellite and beam configuration 75

Appendix 11: Annotated bibliography of useful books and websites Webite: roipac.org ROI_PAC Wiki has the most up-to-date information on software contributed by the community, new ROI_PAC releases and patches, and a place to ask and see answers to common questions. After a spambot attack in 2013, the website is up again in 2014, but functionality is limited. A new web presence integrating discussion of ROI_PAC with the ISCE and GMTSAR software is planned. Shortcourse notes and videos: From 2008-2013, UNAVCO has hosted annual short courses of 2.5-3 days entitled: InSAR: An introduction to Processing and Applications for Geoscientists and has posted the lecture notes used. In 2011, videos of most of the lectures were made and the files used were also posted: http://www.unavco.org/education/advancing-geodetic-skills/short-courses/2011/insar/coursematerials/course-materials.html Shortcourse notes & InSAR textbook: In 2007, the European Space Agency had an Advanced Training course on Land Remote Sensing that included significant information on SAR, InSAR, and optical data and analysis software. At the following webpage you can access lecture notes and a publication "InSAR Principles: Guidelines for SAR Interferometry Processing and Interpretation", ESA TM-19, http://earth.esa.int/landtraining07/material.html Shortcourse notes: A 2-week class was offered in 2009 called Geodetic Earth Observation Technologies for Thailand and the lecture notes from this course taught by Andy Hooper and Miguel Caro Cuenco are available at: http://www.sv.eng.chula.ac.th/index.php/insar-training Shortcourse notes: As part of a 2011 workshop called PASI: Volcanic Hazards and Remote Sensing in Pacific Latin America, Zhong Lu gave 1 day worth of lectures on SAR, InSAR and applications. His lecture notes are available here: http://vhub.org/resources/303 Website: The open source COSI-CORR software for optical pixel tracking is available with extensive documentation at: http://www.tectonics.caltech.edu/slip_history/spot_coseis/index.html Other references: Good overview of classical & space based geodesy (but no InSAR): John Wahr s online textbook http://samizdat.mines.edu/geodesy Introduction to GPS: http://www.trimble.com/gps/index.shtml; Tom Herring s class notes at MIT: http://geoweb.mit.edu/~tah/12.540/ Introductions to InSAR: 2 page overview from Physics Today (Pritchard, 2006) http://www.geo.cornell.edu/eas/peopleplaces/faculty/matt/vol59no7p68_69.pdf New book for a people with limited radr background: Ferretti, 2014 Overviews of applications: Massonnet & Feigl, 1998; Burgmann et al., 2000. More advanced InSAR: The definitive SAR book: Curlander & Mcdonough, 1990 More technical reviews: Rosen et al 2000; Hanssen, 2001; Simons & Rosen, 2007; 76

Time series analysis: Berardino et al., 2002; Schmidt & Burgmann, 2003 Persistent scatterers: Ferretti et al., 2001; Hooper et al., 2004, 2012; Kampes, 2006; Ferretti, 2014 77

References Agram, P. S., R. Jolivet, B. Riel, Y. N. Lin, M. Simons, E. Hetland, M. P. Doin, and C. Lassere, 2013, New Radar Interferometric Time Series Analysis Toolbox Released, Eos, 94, p. 69 Barbot et al., 2008, JOURNAL OF GEOPHYSICAL RESEARCH, VOL. 113, B03403, doi:10.1029/2007jb005063, Space geodetic investigation of the coseismic and postseismic deformation due to the 2003 Mw7.2 Altai earthquake: Implications for the local lithospheric rheology Bechor and Zebker, 2006, GEOPHYSICAL RESEARCH LETTERS, VOL. 33, L16311, doi:10.1029/2006gl026883, Measuring two-dimensional movements using a single InSAR pair. Berardino, P., G. Fornaro, R. Lanari, and E. Sansosti, 2002, A new algorithm for surface deformation monitoring based on small baseline differential SAR interferograms, IEEE Transactions on Geoscience and Remote Sensing, v. 40, p.2375-2383. Biggs J Amelung F, Gourmelen N, et al., InSAR observations of 2007 Tanzania rifting episode reveal mixed fault and dyke extension in an immature continental rift Geophys. J. Int., v.179, p.549-558-669, 2009. Bürgmann, R., P. A. Rosen, and E. J. Fielding, Synthetic Aperture Radar Interferometry to measure Earth s surface topography and its deformation, Ann. Rev. Earth Planet Sci., 28, p. 169-209, 2000. Curlander, J. C., and R. N. McDonough, 1991, Synthetic aperture radar: systems and signal processing, John Wiley & Sons, Inc. New York. Dzurisin, D. Volcano deformation: Geodetic monitoring techniques, Spring-Praxis Publishing, 441 pp., 2007. Ferretti, A., Prati, C., Rocca, F., 2001. Permanent scatterers in SAR interferometry. IEEE Transactions on Geoscience and Remote Sensing 39 (1), 8 20. Ferretti, A., 2014. Satellite InSAR data: Reservoir monitoring from space, European Association of Geoscientists and Engineers, Houten, The Netherlands, 159 pp. Gurrola, E., P. Rosen, G. Sacco, W. Szeliga, H. Zebker, M. Simons, D. Sandwell, P. Shanker, C. Wortham, and A. Chen (2010). InSAR Scientific Computing Environment. 2010 American Geophysical Union Meeting. Hanssen, R. F., 2001, Radar interferometry: Data Interpretation and Error Analysis, Kluwer Academic Press, 308 pp. Hooper, A., H. Zebker, P. Segall, and B. Kampes, New method for measuring deformation on volcanoes and other natural terrains using InSAR persistent scatterers, Geophys. Res. Lett., 31, 10.1029/2004GL021737, 2004. 78

Hooper, A., D. Bekaert, K. Spaans, M. Arikan, 2012, Recent advances in SAR interferometry time series analysis for measuring crustal deformation, Tectonophysics, 514-517, p. 1-13. Jolivet, R., R. Grandin, C. Lasserre, M. P. Doin, and G. Peltzer, 2011, Systematic InSAR tropospheric phase delay corrections from global meteorological reanalysis data, Geophys. Res. Lett., 38, L17311. Jung et al., 2009:IEEE TRANSACTIONS ON GEOSCIENCE AND REMOTE SENSING, VOL. 47, NO. 8, AUGUST 2009 2859, An Improvement of the Performance of Multiple- Aperture SAR Interferometry (MAI) Kampes, B. M., 2006, Radar Interferometry: Persistent Scatterer Technique, Springer Publishing, 211 pp. Leprince, S. S. Barbot, F. Ayoub, and J.-P. Avouac, Automatic and precise orthorectification, coregistration, and subpixel correlation of satellite images, application to ground deformation measurements, IEEE Trans. Geosci. Rem. Sensing, 45, p. 1529-1558, 2007. Lu & Dzurisin, 2010 JOURNAL OF GEOPHYSICAL RESEARCH, VOL. 115, B00B03, doi:10.1029/2009jb006970, Ground surface deformation patterns, magma supply, and magma storage at Okmok volcano, Alaska, from InSAR analysis: 2. Coeruptive deflation, July August 2008 Massonnet, D., and K. Feigl, Radar interferometry and its application to changes in the Earth s surface, Rev. Geophys. 36, p. 441-500, 1998. Pritchard, M. E., M. Simons, P. A. Rosen, S. Hensley and F. H. Webb (2002) Coseismic slip from the July 30, 1995, Mw = 8.1 Antofagasta, Chile, earthquake as constrained by InSAR and GPS observations. Geophysical Journal International 150, 362-376. Pritchard, M. E. and M. Simons (2004) Surveying volcanic arcs with satellite radar interferometry: The central Andes, Kamchatka, and beyond. GSA Today 14, 4-10. Pritchard, M. E. (2006) InSAR, a tool for measuring Earth's surface deformation, Physics Today, July, pg. 68-69 Pritchard, M. E., E. O. Norabuena, C. Ji, R. Boroschek, D. Comte, M. Simons, T. Dixon, and P. A. Rosen (2007) Geodetic, teleseismic, and strong motion constraints on slip from recent southern Peru subduction zone earthquakes, J. Geophys. Res., 112, doi:10.1029/2006jb004294 Rosen, P. A., S. Hensley, I. R. Joughin, F. K. Li, S. N. Madsen, E. Rodriguez, and R. M. Goldstein, Synthetic Aperture Radar Interferometry, Proceedings of the IEEE, 88, p. 333-382, 2000. Rosen, P. A., S. Hensley, G. Peltzer, and M. Simons, Updated Repeat Orbit Interferometry Package released, Eos, 85, p. 47, 2004. 79

Rosen, P. et al. (2009). InSAR Scientific Computing Environment. 2009 American Geophysical Union Meeting. Also presented a summary of InSAR SCE and progress at the WinSAR meeting at Fall AGU 2009 Sandwell, D., R. Mellors, X. Tong, M. Wei, and P. Wessel (2011), Open radar interferometry software for mapping surface deformation, Eos Trans. AGU, 92(28), doi:10.1029/2011eo280002. Scambos, T. A., J. Dutkiewicz, J. C. Wilson, and R. A. Bindschandler, Application of image cross-correlation to the measurement of glacier velocity using satellite image data, Remote Sens. Environ., 42, p. 177-186, 1992. Schmidt, D. A., and R. Bürgmann, Time-dependent land uplift and subsidence in the Santa Clara Valley, California, from a large interferometric synthetic aperture radar data set, J. Geophys. Res., 108, 10.1029/2002JB002267, 2003. Simons, M., and P. A. Rosen, Interferometric Synthetic Aperture Radar Geodesy, in Treatise on Geophysics, vol. 3, G. Schubert (editor), Elsevier Press, p. 391-446, 2007. Wdowinski, S., F. Amelung, F. Miralles-Wilhelm, T. H. Dixon, and R. Carande (2004), Spacebased measurements of sheet-flow characteristics in the Everglades wetland, Florida, Geophys. Res. Lett., 31, L15503, doi:10.1029/2004gl020383. Whelley, P. L., J. Jay, E. S. Calder, M. E. Pritchard, N. J. Cassidy, S. Alcaraz, and A. Pavez (2012) Post-depositional fracturing and subsidence of pumice flow deposits: Lascar volcano, Chile, Bulletin of Volcanology, 74, p. 511-531, DOI: 10.1007/s00445-011-0545-1 Zebker, H., S. Hensley, P. Shanker, C. Wortham (2010). Geodetically Accurate InSAR Data Processor. IEEE Trans. On Geoscience and Remote Sensing, 48(12). 80