Ask a question

Enter questions and answers or comments here (you must be registered and logged in). All registered users are welcome to add to this page. Please subscribe to this page if you want to receive e-mail notification of new questions or answers.

Contents

  1. Ask a question
    1. How do I become a member of ROI_PAC Wiki?
    2. Problem in processing in step [flatorb unwrapped]
    3. Problem with the SNAPHU unwrapping method
    4. Problem with running and MDX
    5. process_2pass.pl raw2ampintcor.pl failed in process_2pass.pl
    6. make_raw.pl fails
    7. Where can I get PRC orbit data for ERS2?
    8. Too few points left after culling error
    9. Installing on a Mac
    10. Problem with test data
    11. Using state vector info for ENVISAT
    12. Why was ROI_PAC only designed to process raw data?
    13. Processing Seasat data
    14. Using ESA orbits for Envisat
    15. YMAX bigger than FILE_LENGTH?
    16. How to skip multilooking ?
    17. How can I process a subset of my SAR image?
    18. Problems selecting an area of interest
    19. Compiling problems
    20. Processing TerraSAR-X SLCs?
    21. Using make_raw.pl with CEOS data from EODC and other ground stations?
    22. PALSAR pairs which won't register?
    23. Simulated SAR image (from DEM) contains stripes
    24. Can Sky Telemetry Format be processed?
    25. How to convert unwrapped phase to range change?
    26. How can I geocode the wrapped interferogram with geomap.trans?
    27. Question about ROI_PAC test run
    28. Radiometric correction/calibration on the *.amp files?
    29. How can I use a DEM in UTM projection?
    30. Can't visualize date.slc file
    31. Can ROI-PAC work with different client processing at the same time?
    32. Fortran runtime error
    33. Masking failed
    34. Offset Tracking
    35. Missing Keywords
    36. Snaphu unwrap
    37. ALOS PALSAR ERSDAC
    38. Polar Stereo DEM
    39. Envisat ASAR long strip subsetting package
    40. How can I skip DEM coregistration?
    41. how can I use bridge.pl
    42. using of make_los.pl
    43. How to Properly Install and Use MDX

How do I become a member of ROI_PAC Wiki?

1. Create your user account (register). It is strongly recommended to use FirstnameLastname (with no space between words--a WikiName) as your username.

2. Send an email to FariaChowdhury or EricFielding requesting to be added as a member. Please include some information about your interest in ROI_pac and tell us what username you have registered.

You need to do both of these steps if you want to be able to modify pages other than this question and answer page.

Problem in processing in step [flatorb unwrapped]

i have a problem in roi_pac in step [flatorb unwrapped] and i could not solve this. can somebody help please? 

Creating ampmag.off  Creating ampmag.in Creating ampmag.out +offset.pl Reading resource file: 19990915-19991020_4rlks.cor.rsc +offset.pl Reading resource file: SIM_4rlks.hgt.rsc +offset.pl Writing resource file: ampmag.off.rsc +offset.pl Writing input_file: ampmag.in +offset.pl /home/dave/roi/ROI_PAC_3_0_1/ROI_PAC/INT_BIN/ampcor ampmag.in rds > ampmag.out +synth_offset.pl Culling points Too few points left after culling, 1 left +dem2diff.pl synth_offset.pl failed in dem2diff.pl +process_2pass.pl dem2diff.pl failed in process_2pass.pl dave:~/Desktop/hector_mine/run1>

Problem with the SNAPHU unwrapping method

When I process the SAR data using SNAPHU method, I found that SNAPHU unwraps everything, even the area in the sea. In some cases, the coherence of some pixels in the sea or mountain are not zero (even very high, e.g., 0.7). Generally speaking, we don't want to unwraps this areas with very sparse high coherence pixels. However, the SNAPHU method will unwrap all this area.

My question is, how can I mask these area (sea, mountain etc.) when unwrapping with SNAPHU method?

Thanks in advance.

Problem with running and MDX

+make_offset.pl Too few points after using range offset 294814 and azimuth offset 305, try values 0.01&0.01  +offset.pl Checking I/O Creating 19980304-20010117_ampcor_gross.off Creating 19980304-20010117_ampcor_gross.in Creating 19980304-20010117_ampcor_gross.out +offset.pl Reading resource file: 19980304.slc.rsc +offset.pl Reading resource file: 20010117.slc.rsc +offset.pl Writing resource file: 19980304-20010117_ampcor_gross.off.rsc +offset.pl Writing input_file: 19980304-20010117_ampcor_gross.in +offset.pl /home/dave/roi/ROI_PAC_3_0_1/ROI_PAC/INT_BIN/ampcor 19980304-20010117_ampcor_gross.in rds > 19980304-20010117_ampcor_gross.out +make_offset.pl /home/dave/roi/ROI_PAC_3_0_1/ROI_PAC/INT_BIN/fitoff 19980304-20010117_ampcor_gross.off 19980304-20010117_cull_gross.off 1.5 0.5 10 > fitoff_ampcor_gross.out +make_offset.pl 2 points left after culling  Still too few points left after culling with 0.01/0.01 offsets : 2 left +raw2ampintcor.pl make_offset.pl failed in raw2ampintcor.pl +process_2pass.pl raw2ampintcor.pl failed in process_2pass.pl

Either something went wrong with your "make_raw" for this data or you have two scenes from different tracks. The impossibly large range offset range offset 294814 means that ROI_pac believes the two scenes are hundreds of km apart.

Unfortunately, the JPL Software Licensing Authority can take a very long time to respond to MDX license requests. For researchers outside of the USA, the process can take several months. There are some other solutions listed on the Viewing_results page.

process_2pass.pl raw2ampintcor.pl failed in process_2pass.pl

abid@abid-laptop:~/Desktop/ROI/ROI_PAC_3_0_1/run1$ process_2pass.pl param.txt +process_2pass.pl Read the inputfile +process_2pass.pl Define Variables +process_2pass.pl Go from raw to slc to int and cor (also flattens with orbits) Usage: raw2ampintcor.pl Function: Goes from the raw ERS data to interferogram and correlation images *** Last Update Aug 18, 1999 *** For more info see http://roipac.org *** This software is part of the ROI_PAC suite. *** Licensed software, not for general distribution. +process_2pass.pl raw2ampintcor.pl failed in process_2pass.pl

You need to add the required information to the "param.txt" file. See the ROI_pac Internals document for explanation of the parameters.

make_raw.pl fails

abid@abid-laptop:~/Desktop/ROI/ROI_PAC_3_0_1/run1/19931124$ make_raw.pl ODR SARLEADER19931124151441 19931124 +make_raw.pl Checking I/O Creating 19931124.raw Creating 19931124.raw.rsc +make_raw.pl General definitions +make_raw.pl Getting facility name +make_raw.pl Finding reference counter, pri and prf counter read: 812 swst offset read: 214 +make_raw.pl Reference counter = 812 +make_raw.pl Checking line number +make_raw.pl /home/abid/Desktop/ROI/ROI_PAC_3_0_1/ROI_PAC/INT_BIN/new_parse 11644 210 4 1 IMAGERY19931124151441 tmp_IMAGERY.raw 29000060 +make_raw.pl Reading the leader file +make_raw.pl /home/abid/Desktop/ROI/ROI_PAC_3_0_1/ROI_PAC/INT_BIN/leader2rsc SARLEADER19931124151441 /home/abid/Desktop/ROI/ROI_PAC_3_0_1/ROI_PAC/multibuild-100118-1757/installs/share/roi_pac/format_leaderfile_D-PAF tmp_IMAGERY.raw.rsc +make_raw.pl Reading the imagery file +make_raw.pl Setting the starting range +make_raw.pl /home/abid/Desktop/ROI/ROI_PAC_3_0_1/ROI_PAC/INT_BIN/delay_shift tmp_IMAGERY.raw tmp_IMAGERY.new shift.out 214 812 11644 412 11636 0 0 shifting line 0 shifting line 10000 shifting line 20000 +make_raw.pl Writing the imagery resource file +make_raw.pl Reading state vectors in SARLEADER's header, Building hdr_data_points_19931124 file +state_vector.pl getorb failed in state_vector.pl +make_raw.pl state_vector.pl failed in make_raw.pl

You need to have the University of Delft ODR orbit package installed to use the ODR orbit option in "make_raw.pl". This is not part of ROI_pac, so you have to install it separately if you want to use it. See the README. You can always use the "HDR" orbit option that uses the state vectors in the SARLEADER file. These may not be as accurate, but they are always available.

Where can I get PRC orbit data for ERS2?

You should contact the ESA Earth Observation (EO) Help Desk < eohelp@eo.esa.int > to ask for a password to their FTP site for the PRC orbits.

Too few points left after culling error

+offset.pl Writing input_file: 960919-000928_ampcor.in +offset.pl /disk1/localrhel/insar/ROI_PAC_3_0/ROI_PAC/INT_BIN/ampcor 960919-000928_ampcor.in rdf > 960919-000928_ampcor.out +make_offset.pl /disk1/localrhel/insar/ROI_PAC_3_0/ROI_PAC/INT_BIN/fitoff 960919-000928_ampcor.off 960919-000928_cull.off 1.5 0.08 50 > fitoff_ampcor.out Too few points left after culling: 2 left +raw2ampintcor.pl make_offset.pl failed in raw2ampintcor.pl +process_2pass.pl raw2ampintcor.pl failed in process_2pass.pl

There are a lot of reasons this step can fail. It is possible that bad orbit data could cause the baseline.pl script to not be able to estimate the gross offset. You should also apply the patch to baseline.pl from the Patches page. There are more hints on this web page: http://www.geo.cornell.edu/eas/PeoplePlaces/Faculty/matt/troubleshooting.html

Installing on a Mac

+offset.pl /Users/Gerardo/Desktop/Insar/ROI_PAC_3_0/ROI_PAC/multibuild-090402-1132/installs/defaults/bin/ampcor 930110-950523_ampcor_gross.in rdf > 930110-950523_ampcor_gross.out sh: line 1: 51214 Bus error /Users/Gerardo/Desktop/Insar/ROI_PAC_3_0/ROI_PAC/multibuild-090402-1132/installs/defaults/bin/ampcor 930110-950523_ampcor_gross.in rdf > 930110-950523_ampcor_gross.out +offset.pl ampcor failed in offset.pl

I think I remember this kind of bus error with a version of the gfortran compiler. What compiler and version did you use?

Problem with test data

make_raw.pl PCR SARLEADER1993011018252739T1Of1 930110 +make_raw.pl Checking I/O Creating 930110.raw Creating 930110.raw.rsc +make_raw.pl General definitions +make_raw.pl Getting facility name +make_raw.pl Finding reference counter, pri and prf counter read: 900 swst offset read: 204 +make_raw.pl Reference counter = 900 +make_raw.pl Checking line number +make_raw.pl /new_parse 12060 200 4 1 IMAGERY1993011018252739T1Of3 tmp_IMAGERY.raw +make_raw.pl Reading the leader file +make_raw.pl /leader2rsc SARLEADER1993011018252739T1Of1 /disk1/localrhel/insar/ROI_PAC_3_0/ROI_PAC/INT_SCR/format_leaderfile_CRDC-SARDPF tmp_IMAGERY.raw.rsc tmp_IMAGERY.raw has zero size

I think you have a typo in your command it says "PCR" instead of "PRC" for the orbit type. It also looks like you did not define the INT_BIN environment variable.

Using state vector info for ENVISAT

No, the Envisat Level 0 (raw) data files only contain one state vector, which is not sufficient for processing. You must get the orbit information from either the ESA DORIS orbit files or the Delft ODR orbits.

Why was ROI_PAC only designed to process raw data?

Yes, ROIpac was designed to process the two images at the average of the two Doppler centroids. It does the azimuth spectrum filtering (cutting out the part of the azimuth spectrum that does not overlap) in the "roi" program. It is possible to do the azimuth spectrum filtering in the interferogram formation, but this is not what "resamp_roi" does. The Delft DORIS software does the filtering in the interferogram stage, as it must because it starts with SLCs.

In addition, there is another significant difference between the way that ROIpac and other SAR processors use the Doppler centroid in the SLC formation. ROIpac is set up to process the SLC in the original geometry, but the ESA processor (and probably the Canadian Radarsat-1 processor) produce the SLC images in a deskewed geometry. The deskewing moves the data to adjust for the squint or angle between the radar LOS and perpendicular to the orbit track. Because the Radarsat-1 data has a large squint (typically about 3 degrees at middle latitudes), this is a large effect. This will make it extremely difficult if not impossible to combine ROIpac SLCs with the SLCs from the other processor.

It should be possible to make interferograms between two SLCs processed by the same system as long as the Doppler centroids are not too different. We did this with the Bam earthquake Envisat ASAR SLCs before we got the raw data. You should set the Doppler centroid to zero in the .slc.rsc file if you use ROIpac to process deskewed SLC data.

Processing Seasat data

The .raw.rsc files are not really necessary if you are running the roi program without the Perl scripts. The Perl scripts read the .rsc files to create the .rdf file, and the program only reads the .rdf file and the data files. To use the rest of the ROI_pac Perl scripts, you would want to create the .slc.rsc file for the output from roi. 

i/q means (-) = 15.6555004 15.3079996 15.6555004 15.3079996 ! file 1 (i,q), file 2 (i,q) Flip i/q? (-) = n                               !

Seasat data is offset video so obviously does not have i/q. Does roi assume IQ? If so do I have to write a program that demodulates Seasat to baseband IQ? If not, how do I tell roi that my data is offset video? Or is there a separate routine that handles non complex data.

The roi program definitely processes offset-video data. I used it many times for SIR-C data that is offset video. You just need to put "o" (for offset video) in the "Flip i/q?" answer. It will do the decoding automatically.

Using ESA orbits for Envisat

When you use the DOR option in make_raw_envi.pl, the script copies the Envisat DORIS orbit data from ESA (either POR orbits from $POR_DIR or VOR orbits from $VOR_DIR) to a hdr_$date.rsc file. The rest of the processing should then be done with the $orbit_type set to HDR. This was a shortcut to avoid modifying the state_vector.pl script to read the Envisat DORIS orbit files.

YMAX bigger than FILE_LENGTH?

//////My PALSAR Data////// Mode     : FBS Level    : 1.0 off-nadir angle : 34.3 Orbit Direction : Descending PRF : 2145.923000(Same PRF) SceneShift      : -4 //////*.PRM////// num_rng_bins     11304 bytes_per_line   21100 good_bytes_per_line     21020 num_lines        35193 //////*.raw.rsc////// FILE_LENGTH      35193 XMIN     413 XMAX     21020 WIDTH    21100 YMIN     0 YMAX     35193 //////*.slc.rsc////// FILE_LENGTH      38680 XMIN     0 XMAX     10303 WIDTH    10303 YMIN     0 YMAX     40564

In ROI_pac it is normal for the YMAX of the SLC to be larger than the YMAX of the raw data. The difference is larger for PALSAR because it has a longer synthetic aperture. It is not clear why the YMAX of the SLC is larger than the FILE_LENGTH parameter. Are you using the ROI_pac v. 3.0 scripts?

How to skip multilooking ?

To process the interferogram with no range looks (but still having azimuth looks determined by the pixel_ratio), you need to change three values to change the number of range looks: 

Rlooks_int=1 Rlooks_unw=1 Rlooks_sim=1

How can I process a subset of my SAR image?

You can process a subset of the raw data file using a roi.proc file in the directory above the directories of the individual dates. This file is used to determine which part of the raw data to process for all of the dates. You can also put a file into the directories of the individual dates called $date.proc (whatever the name of your $date directory) with the same information. It should contain all the parameters you want to change in the processing of the raw data to SLC. For example: 

before_z_ext = -1000 after_z_ext = -12000 near_rng_ext = -0 far_rng_ext = -3950

All of the "_ext" values are "extensions" from the area of the raw data, so negative extensions mean that the SLC will be smaller than the raw data. The default values are calculated in roi_prep.pl but the .proc file values will override the defaults.

Problems selecting an area of interest

before_z_ext = -13900 after_z_ext = -7076 near_rng_ext = -5900 far_rng_ext = -2250 

Creating 19960423.slc +roi.pl ROI_PAC_3_0/ROI_PAC/INT_BIN/roi 19960423_roi.in > 19960423_roi.out At line 812 of file ROI_PAC_3_0/ROI_PAC/roi/roi.F Fortran runtime error: RECL parameter is non-positive in OPEN statement +roi.pl roi failed in roi.pl +raw2ampintcor.pl roi.pl failed in raw2ampintcor.pl +process_2pass.pl raw2ampintcor.pl failed in process_2pass.pl

The important thing to note is that the WIDTH in the .raw.rsc file is in bytes and there are two bytes for every data sample. The range extension values must be specified in samples, so you probably need to divide your near_rng_ext and far_rng_ext values by two. The width of most SAR images is around 6000 samples, so the near_rng_ext and far_rng_ext values you used add to much more than the full width. Also, for ERS data, there are usually an extra 412 bytes at the beginning of each raw data line XMIN 412 and this further reduces the width of the actual data.

Compiling problems

As you may know, "segmentation violation" errors can be caused by a number of things. The first thing to check is whether the 930110_roi.in file has anything strange in it. Another thing to check is the build and link to the FFTW libraries. It is strongly recommended that you use the contrib/install-fftw.sh script to build FFTW with the required single-precision code and use that. Other FFTW builds are not likely to work. If the FFTW build is bad or incompatible, then all of the programs that use them will fail.

Core file generation is controlled by your shell. Often the "coredumpsize" is set to zero in the shell, which causes no core files to be created. Under Linux csh-type shells, you can use limit core 10m to set the limit to 10 MB.

You probably need to compile the code with the debugging symbols to use gdb effectively. You can build ROI_pac with the debugging flag -g by using the gfortran-g build of contrib/multibuild.sh. Another debugging tool in Linux is strace which will print information about all the system calls made by the program.

Processing TerraSAR-X SLCs?

I have not done this myself, but I have seen another person's TerraSAR-X interferogram. If you have not used ROI_pac before, I would recommend processing the sample dataset and examining the .slc.rsc files that contain the metadata about the .slc images.

Using make_raw.pl with CEOS data from EODC and other ground stations?

elsif ($facility eq "EODC") { $facility = "UK-PAF";} 

Keyword FIRST_FRAME_SCENE_CENTER_LINE doesn't exist in tmp_IMAGERY.raw.rsc, returning 0 Keyword FIRST_CENTER_HOUR_OF_DAY doesn't exist in tmp_IMAGERY.raw.rsc, returning 0 Keyword FIRST_CENTER_MN_OF_HOUR doesn't exist in tmp_IMAGERY.raw.rsc, returning 0 Keyword FIRST_CENTER_S_OF_MN doesn't exist in tmp_IMAGERY.raw.rsc, returning 0 Keyword FIRST_CENTER_MS_OF_S doesn't exist in tmp_IMAGERY.raw.rsc, returning 0 

No good range counter found using reference counter = 4114

elsif ($facility eq "EODC") { $facility = "D-PAF";}

The first thing to try is just specifying the facility on the make_raw.pl command line. It is an optional fourth parameter. This will allow you to try the different facility types already supported without changing the Perl script. It sounds like your modifications were not working correctly.

If you are sure that none of the existing facilities will work for your data, then you need to find a reference document for the facility that processed your data. The help desk of that facility may be able to help.

PALSAR pairs which won't register?

Too few points left after culling, 2 left

The version 3.0.1 should handle PRF differences much better than previous versions. The new version uses the difference between the PRF values to calculate a scale factor for the azimuth direction and uses this in the matching.

If the gross matching was good and resulted in a good number of points, then the initial offsets from the orbits must be OK.

If you specify y_start, then you should also specify the x_start. Normally both are integers.

Radio-frequency interference is a big problem for PALSAR data in some areas, depending on the local use of L-band radio frequencies.

Running "PlotOffset.pl" on the *ampcor.off file should help diagnose why the fine culling is failing. You will need to install the "xmgrace" program if you don't already have it.

Simulated SAR image (from DEM) contains stripes

synth_offset.pl Culling points dem2diff.pl synth_offset.pl failed in dem2diff.pl process_2pass.pl dem2diff.pl failed in process_2pass.pl

simrawio9

The SIM_raw.hgt file almost always has some voids in it, with the pattern depending on how the DEM spacing is mapped into the SAR image coordinates. If the DEM has a coarser spacing than the SAR data, then the voids can be a majority of the pixels. Normally, the "Aik_resample" program that is run after IntSim interpolates over these voids to produce a SIM_4rlks.hgt (or similar) file that is used in the rest of the processing.

You should compare the SIM_4lks.hgt file to the date1-date2_4rlks.cor file to see if they look similar because those are the files that are matched by "synth_offset.pl"

Can Sky Telemetry Format be processed?

The Sky Telemetry Format (STF) data from ASF cannot be ingested with the programs released with ROI_pac v. 3.0. The data format is completely different, so it requires a different program to read the STF level 0 data. We hope to include the STF data reading program and associated scripts with the 3.0.1 release.

How to convert unwrapped phase to range change?

The unwrapped phase can be converted to range change by multiplying the phase (in radians) by the radar wavelength/4*pi with the length units of the wavelength.

How can I geocode the wrapped interferogram with geomap.trans?

If you already have the geomap(_4rlks).trans file from a successful run of process_2pass.pl, then you can geocode the wrapped interferogram (.int) file.

Unfortunately, the geocode.pl script only knows how to geocode the unwrapped interferograms. To geocode the wrapped interferogram, you need to edit the rect_lookup.in file to change the input file name to your date1-date2(_4rlks).int file (must have the same number of looks as the geomap.trans file) and the output file name to whatever you want to call the output. You also need to change the "file type" to CPX and the "Interpolation Method" to Sinc. Then run the rect_lookup" program with the edited input file rect_lookup rect_lookup.in.

-

Question about ROI_PAC test run

+offset.pl /export/software/roi_pac/bin/ampcor 930110-950523_ampcor_gross.in rdf > 930110-950523_ampcor_gross.out

The ampcor program can take a while to run, but it should finish in less than 10 minutes on a reasonably fast computer.

Radiometric correction/calibration on the *.amp files?

No, ROI_pac does not do any radiometric corrections or calibrations. All of the SAR amplitude images are completely uncalibrated. ROI_pac is only designed to accurately process the interferometric phase.

How can I use a DEM in UTM projection?

ROI_pac does not require the full zone code with the letter specifying the latitude band, just the zone number appended to "UTM". 28n057e-31n060e.srtm3-utm40-160m.dem.rsc is an example of a .dem.rsc file for UTM zone 40. Note that the Y_STEP is negative if your DEM goes from north to south in its scan lines, for UTM or LATLON projections.

Can't visualize date.slc file

Cannot open the filename: date.slc STOP set number less than or equal to zero statement executed

It sounds like your MDX program was not compiled with the large file flags, so it does not know how to open a >2 GB SLC file.

Can ROI-PAC work with different client processing at the same time?

There should be no problem with running ROI_pac on different terminals at the same time, as long as you are processing different data. You can't process the same scene as part of two different pairs at the same time (unless you make a separate copy of the raw and slc directory for the date) because ROI_pac focuses the SLC optimized for each pair.

Fortran runtime error

+phase2base.pl Checking I/O Creating phase2base.out  +phase2base.pl Reading resource file: 930110-950523_cull.off.rsc  +phase2base.pl Reading resource file: radar_4rlks.hgt.rsc  +phase2base.pl Reading resource file: pha4baseest.unw.rsc  +phase2base.pl Writing baseest input_file: phase2base.in with QUAD fit  At line 400 of file baseest.f Fortran runtime error: End of file  +phase2base.pl baseest failed in phase2base.pl  +process_2pass.pl phase2base.pl failed in process_2pass.pl

The first thing to check is whether the "pha4baseest.unw" and "radar_4rlks.hgt" files both look correct and have the same length. 

radar_4rlks.hgt.rsc WIDTH                                    1425 FILE_LENGTH                              648 XMIN                                     0 XMAX                                     1424 YMIN                                     0 YMAX                                     647 pha4baseest.unw.rsc MSK_THRESHOLD                            0.1 WIDTH                                    1425 FILE_LENGTH                              648 XMIN                                     0 XMAX                                     1425 YMIN                                     0 YMAX                                     648

Your two images look the same. One should be the simulated interferogram, but since the files are the same size, this is probably not your problem.

I remember there was a certain version of "gfortran" that had a problem somewhere, maybe here. I (Eric Fielding) use gfortran v. 4.5.1 successfully. You might try a newer version of gfortran.

Masking failed

+make_mask.pl mag_phs2cpx  pwr sigma phase_var_ODR_4rlks.int 1425 line 1400+make_mask.pl int_thr  phase_var_ODR_4rlks.int phase_var_ODR_4rlks_thresh.int 1425 5e-05 +make_mask.pl cpx2mag_phs  phase_var_ODR_4rlks_thresh.int /dev/null phase_var_ODR_4rlks_thresh 1425 line 1400+make_mask.pl add_phs  phase_var_ODR_4rlks_thresh phs final_mask 1425 1455 0 1 +make_mask.pl mag_phs2rmg  pwr final_mask phase_var_ODR_4rlks.msk 1425 line 1400Ended at make_mask +process_2pass.pl int2filtmaskunwrap.pl failed in process_2pass.pl

Hello, I would suggest looking at the "phase_var_ODR_4rlks.int" and "phase_var_ODR_4rlks.msk" files. The files should have the same size and look like images. The .int files are complex and .msk files are RMG. See the ShortCourse page for the Internals document that explains more about what should be in these files.

Offset Tracking

Missing Keywords

Keyword RANGE_OFFSET doesn't exist in 970613.raw.rsc, returning 0 Keyword RANGE_OFFSET doesn't exist in 970718.raw.rsc, returning 0 Keyword HEADING_DEG doesn't exist in reference.hgt.rsc, returning 0 Keyword AZIMUTH_PIXEL_GROUND doesn't exist in reference.hgt.rsc, returning 0 Keyword DATUM doesn't exist in /data/mmmm/DEM/nnnn.dem.rsc, returning 0

You can ignore these warnings in the processing. Check to the SIM/IntSim.out file to make sure your DEM covers the area of the SAR scene.

Snaphu unwrap

+add_rmgAmpPhs.pl Adding back +add_rmgAmpPhs.pl /disk1/localrhel/insar/ROI_PAC_3_0_1/BIN/add_rmgAmpPhs 080427-090412-sim_HDR_8rlks.rmg \                               phase_var_080427-090412-sim_HDR_8rlks.msk \                               phase_var_080427-090412-sim_HDR_8rlks.rmg \                               710   \                               635  \                               0   \                               1 +rmg2cpx.pl Checking I/O Infiles newer than phase_var_080427-090412-sim_HDR_8rlks.int Infiles newer than phase_var_080427-090412-sim_HDR_8rlks.int.rsc +snaphu_mask.pl unwrapping masked interferogram file: phase_var_080427-090412-sim_HDR_8rlks.int +snaphu_mask.pl creating snaphu configuration file: 080427-090412-sim_HDR_8rlks.snaphuconf +snaphu_mask.pl running snaphu +snaphu_mask.pl  xmin 0, xmax 709, new_width 710, new_xmax 709 +snaphu_mask.pl  ymin 0, ymax 634, new_length 635, new_ymax 634 +snaphu_mask.pl writing resource file: 080427-090412-sim_HDR_8rlks.unw.rsc +snaphu_mask.pl bash -c '/disk1/localrhel/insar/ROI_PAC_3_0_1/MY_BIN/snaphu -f 080427-090412-sim_HDR_8rlks.snaphuconf -v 1>080427-090412-sim_HDR_8rlks.snaphuout 2>080427-090412-sim_HDR_8rlks.snaphuerr' bash: line 1: 32308 Segmentation fault      /disk1/localrhel/insar/ROI_PAC_3_0_1/MY_BIN/snaphu -f 080427-090412-sim_HDR_8rlks.snaphuconf -v > 080427-090412-sim_HDR_8rlks.snaphuout 2> 080427-090412-sim_HDR_8rlks.snaphuerr +snaphu_mask.pl snaphu failed in snaphu_mask.pl +int2filtmaskunwrapNew.pl snaphu_mask.pl failed in int2filtmaskunwrapNew.pl +process_2pass_master.pl int2filtmaskunwrapNew.pl failed in process_2pass_master.pl

I noticed that after the run my date1-date2_8rlks.cor.rsc is back to the original lenght (635) and the date1-date2_8rlks.cor.rsc.hst report 

20110209-164950 length.pl 20 read WIDTH 710 20110209-164950 length.pl 21 read FILE_LENGTH 636 20110209-164950 length.pl 32 write FILE_LENGTH 635 20110209-164950 snaphu_mask.pl 139 read WIDTH 710 20110209-164950 snaphu_mask.pl 140 read FILE_LENGTH 635 20110209-164950 cor_mask.pl 37 read WIDTH 710 20110209-164950 cor_mask.pl 38 read FILE_LENGTH 635

Somehow during the processing length.pl write back the original value! I can't figure out which is the problem and the way to fix it. Any ideas? thank you for any help!

ALOS PALSAR ERSDAC

Hello! We have a problem, in the file description "make_raw_alos_ERSDAC.pl" the following is told: 

make_raw_alos_ERSDAC.pl  put together by Rob Mellors (7/2010, SDSU) based on make_raw_alos.pl by Yuri Fialko with modifications by Eric Fielding and Zhenlong Li software inputs from Dave Sandwell, Rob Mellors, and Matt Wei * ALOS_* utilities should be installed in $INT_BIN directory * requires version of ALOS_pre_process that create roi_pac output (-roi) * note that ERSDAC data already has a .raw suffix

How it is necessary to satisfy this condition "ALOS_* utilities should be installed in $INT_BIN". It seems to us that we aren't able to do it correctly.

I already have version ALOS_pre_process which reads format ERSDAC. I have installed it in a directory/usr/local/ROI_PAC_3_0_1/ROI_PAC. Then files from a directory/usr/local/ROI_PAC_3_0_1/ROI_PAC/INT_BIN has copied in/usr/local/ROI_PAC_3_0_1/ROI_PAC/bin and has recustomized the variable environments. The file make_raw_alos_ERSDAC.pl has placed in a directory/usr/local/ROI_PAC_3_0_1/ROI_PAC/INT_SCR

What have I made not correctly? 

PASL10C0706100554061101070064.raw   +make_raw_alos_ERSDAC.pl Checking I/O +make_raw_alos_ERSDAC.pl General definitions  Decoding frame 1, PASL10C0706100554061101070064.  Acqsn. mode: W51 fbs2fbd = NO  +make_raw_alos_ERSDAC.pl ALOS_pre_process PASL10C0706100554061101070064.raw PASL10C0706100554061101070064.ldr -nodopp -roi  no doppler calculation (sets to zero!)  writing roi_pac rsc files  .... swapping bytes record_length changed   Illegal division by zero at /usr/local/ROI_PAC_3_0_1/ROI_PAC/INT_SCR/make_raw_alos_ERSDAC.pl line 216.

Polar Stereo DEM

Envisat ASAR long strip subsetting package

Hello! I have some problems on compiling the "Envisat ASAR long strip subsetting" package (http://roipac.org/ContribSoftware#head-6d4dcc018d9dd644fc050d59690b191f36d4389e). When I run " cc -o asa_im_decode-cut asa_im_decode-cut.c", I received the following error: 

asa_im_decode-cut.c: In function ‘readMph’: asa_im_decode-cut.c:1185:4: warning: incompatible implicit declaration of built-in function ‘memcpy’ [enabled by default] asa_im_decode-cut.c:1198:51: warning: incompatible implicit declaration of built-in function ‘strchr’ [enabled by default] asa_im_decode-cut.c: In function ‘readSph’: asa_im_decode-cut.c:1287:4: warning: incompatible implicit declaration of built-in function ‘memcpy’ [enabled by default] asa_im_decode-cut.c:1288:51: warning: incompatible implicit declaration of built-in function ‘strchr’ [enabled by default] asa_im_decode-cut.c: In function ‘readSphAux’: asa_im_decode-cut.c:1387:4: warning: incompatible implicit declaration of built-in function ‘memcpy’ [enabled by default] asa_im_decode-cut.c:1399:48: warning: incompatible implicit declaration of built-in function ‘strchr’ [enabled by default] asa_im_decode-cut.c: In function ‘is_bigendian’: asa_im_decode-cut.c:1659:3: warning: incompatible implicit declaration of built-in function ‘memcpy’ [enabled by default]

Even though there exist many warnings, it still creates the executable file "asa_im_decode-cut". However, when I went to the direction "env_orbit" and run "make", I received the errors below: 

cc    -c -o statevector.o statevector.c statevector.c: In function ‘statevector’: statevector.c:16:23: warning: incompatible implicit declaration of built-in function ‘malloc’ [enabled by default] statevector.c:24:5: warning: incompatible implicit declaration of built-in function ‘exit’ [enabled by default] statevector.c:38:3: warning: passing argument 1 of ‘getline’ from incompatible pointer type [enabled by default] /usr/include/stdio.h:673:18: note: expected ‘char ** __restrict__’ but argument is of type ‘struct FILE *’ statevector.c:38:3: warning: passing argument 2 of ‘getline’ from incompatible pointer type [enabled by default] /usr/include/stdio.h:673:18: note: expected ‘size_t * __restrict__’ but argument is of type ‘char *’ statevector.c:38:3: warning: passing argument 3 of ‘getline’ from incompatible pointer type [enabled by default] /usr/include/stdio.h:673:18: note: expected ‘struct FILE * __restrict__’ but argument is of type ‘double *’ statevector.c:38:3: error: too many arguments to function ‘getline’ /usr/include/stdio.h:673:18: note: declared here statevector.c:41:5: warning: passing argument 1 of ‘getline’ from incompatible pointer type [enabled by default] /usr/include/stdio.h:673:18: note: expected ‘char ** __restrict__’ but argument is of type ‘struct FILE *’ statevector.c:41:5: warning: passing argument 2 of ‘getline’ from incompatible pointer type [enabled by default] /usr/include/stdio.h:673:18: note: expected ‘size_t * __restrict__’ but argument is of type ‘char *’ statevector.c:41:5: warning: passing argument 3 of ‘getline’ from incompatible pointer type [enabled by default] /usr/include/stdio.h:673:18: note: expected ‘struct FILE * __restrict__’ but argument is of type ‘double *’ statevector.c:41:5: error: too many arguments to function ‘getline’ /usr/include/stdio.h:673:18: note: declared here statevector.c:53:5: warning: passing argument 1 of ‘getline’ from incompatible pointer type [enabled by default] /usr/include/stdio.h:673:18: note: expected ‘char ** __restrict__’ but argument is of type ‘struct FILE *’ statevector.c:53:5: warning: passing argument 2 of ‘getline’ from incompatible pointer type [enabled by default] /usr/include/stdio.h:673:18: note: expected ‘size_t * __restrict__’ but argument is of type ‘char *’ statevector.c:53:5: warning: passing argument 3 of ‘getline’ from incompatible pointer type [enabled by default] /usr/include/stdio.h:673:18: note: expected ‘struct FILE * __restrict__’ but argument is of type ‘double *’ statevector.c:53:5: error: too many arguments to function ‘getline’ /usr/include/stdio.h:673:18: note: declared here statevector.c: At top level: statevector.c:66:5: error: conflicting types for ‘getline’/usr/include/stdio.h:673:18: note: previous declaration of ‘getline’ was here make: *** [statevector.o] Error 1

Does any one can tell me how to install the the "Envisat ASAR long strip subsetting" package correctly? Thanks in advance.

How can I skip DEM coregistration?

Sometimes, process_2pass.pl fails to coregister the DEM (SIM_4rlks.hgt) and the interferogram ($date1-$date2_4rlks.cor) if there are not enough topographic features in the area (if the ground is very flat). This will result in the error "not enough points left after culling." Right now, it is not possible to skip the DEM coregistration step. However, ROI_PAC can be forced to use a very rough coregistration and then continue with the processing. If the ground is very flat, using a rough DEM coregistration should not drastically affect the final interferogram.

To force a rough coregistration between the DEM and the interferogram, just replace the existing output file "cull.out" with a fake cull.out file containing null values for all the transformations. An example of this file is below. After the file is replaced, process_2pass.pl can be started again, beginning from "done_sim_off."

cull.out 

      << Fitoff Program >>            Number of points remaining =        1703        RMS in X =   0.230915541821178        RMS in Y =   0.212106453700300                   Matrix  Analysis             Affine Matrix         1    0     0    1     Translation Vector          0       0      Rotation Matrix         1   0     0    1     Rotation Angle (deg) =   0      Axis Scale Factors       1   1      Skew Term       0

-Stephanie Higgins

how can I use bridge.pl

bridge filt_*_4rlks.int filt_*_4rlks_c2.flg filt_*_4rlks_c2.unw bridge_test 74 32 404 478 871 903question rpoipac 

# lines interferogram, unwrapped phase flag file: 30702 61404 30702 array width, height: 74 394 initializing phase array... interferogram file: filt_*_4lrks.int unwrapping flag file: filt_*_4rlks_c2.flg unwrapping phase file: filt_*_4rlks_c2.unw number of points unwrapped: 0 interferofram line: 300 total number of lines: 394 number of valid phase data samples: 16541 fraction of the phase image unwrapped:0.00000 segmentation fault

See information just added to the Phase Unwrapping page http://www.roipac.org/PhaseFiltUnwrap

---

using of make_los.pl

SarDir1=/interfero/.../date1 SarDir2=/interfero/.../date2 IntDir=/interfero/.../int_date1_date2 DEM=/interfero/.../DEM/DEM.dem UnWrappedThreshold=0.02 OrbitType=HDR Threshold_mag=2.5e-5 FilterStrength=0.8 flattening='topo'

You also need to specify the full paths for your SimDir and GeoDir in your data1_date2.proc file for the "make_los.pl" script to work correctly. If you did not specify these in running "process_2pass.pl" then they will be set to SIM and GEO by default in the same directory as your interferogram directory.

---

How to Properly Install and Use MDX

You need to use the "mdx.pl" script that can read the width from the ROI_pac .rsc files and run the "mdx" program with the correct parameters. mdx.pl 930110.slc should display the -c8 format .slc image with magnitude and phase. See the updated Viewing results page for more information.

AskQuestion (last edited 2012-04-29 02:34:00 by EricFielding)