Differences between revisions 21 and 22
|Deletions are marked like this.||Additions are marked like this.|
|Line 11:||Line 11:|
|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.||2. Send an email to LisaChristiansen or EricFielding requesting to be added as a member. Please include some information about your interest in ROI_pac.|
Frequently asked questions
What is the purpose of the ROI_PAC Wiki?
The ROI_pac wiki is for people to share their questions and hints with others, so please register and become a member to edit the pages and contribute to the ROI_pac community.
How do I become a member of ROI_PAC Wiki?
All registered users can ask or answer questions on the question and answer page. Members have the additional permission to modify most other pages in the ROI_PAC Wiki.
Who are the current Wiki members?
Please go to User Home Pages to view the list of members and advanced members.
I just installed ROI_pac version 3.0 and many programs fail to run with a "segmentation violation." What is wrong?
Many things can cause this, but the first thing to check is the FFTW library you have used to build ROI_pac. Compilation problems in FFTW can cause programs that use an FFT to crash. (Answer provided by ZhenhongLi .)
Can I use .raw and .raw.rsc files previously pre-processed by an old version of ROI_pac with the new version 3.0?
It is better to re-run the "make_raw" pre-processing with the new version. Some new parameters were added that are required for processing and improvements were made in parameter calculations.
The build process for the version 3.0 release failed because of a missing "README" file. How can I fix this?
Remember to do the "touch aclocal.m4 Makefile.in configure" command in the ROI_PAC directory before starting the build.
I'm having problems with the new version of ROI_PAC. I've built it on a Sun under f90, but when I run the test data it hangs at ampcor during offsets.
+offset.pl ROI_PAC_3_0/ROI_PAC/multibuild-071029-2116/installs/f90/bin/ampcor 930110-950523_ampcor_gross.in rdf > 930110-950523_ampcor_gross.out Killed
This is usually due to the limit set in your shell. Try using the "limit stacksize unlimited" command before running.
Is it possible to start with the SLC ALOS data processed by ESA instead of the raw data?
ROI_pac is designed to start with raw data. There are no utilities to read SLC data for ALOS or other satellites, except for TerraSAR-X and COSMO-SkyMed. A user has contributed some scripts to read SLC images generated by ESA for Envisat (see http://roipac.org/ContribSoftware). See also http://roipac.org/AskQuestion
I added OrbitType=HDR at the end of my "int.proc" file, but process_2pass.pl is still trying to find ODR orbit files.
Make sure you have a carriage return at the end of the last line in your "int.proc" file. If the last line does not have a carriage return, then the process_2pass.pl script ignores that line. Add a blank line at the end to be safe.
Are the negative phase values in the .unw and .int files subsidence or uplift?
The sign convention of the interferogram will depend on the order of dates you used in the processing. I normally use the “before” date as the master scene and the “after” date as the slave scene. With the ROI_pac software, the interferogram is the phase of the after (slave) date minus the phase of the before (master) date. If the after date is closer to the satellite, then the phase difference is negative. If you assume the motion is vertical, then uplift results in negative phase change. You would need to multiply by –1*wavelength/(4*pi) to convert the phase (in radians) to surface motion in the radar line of sight. Of course, the InSAR phase is always relative to the rest of the scene, so you may need to add a constant to all of the phase values. If you want to make sure you understand the sign convention, I would recommend checking the sign convention of a known deformation such as the coseismic pair for some event.
The SNAPHU program fails immediately when using snaphu.pl or the new unw_method=snaphu. What is wrong?
This is usually caused by a bug in the program that takes looks on the correlation image. You probably will find that your "n"rlks.cor file is larger than your -sim_HDR_"n"rlks.int file.
[Abruzzo/d079/int_080427_090412] fielding% ls -l 080427-090412-sim_HDR_4rlks.int -rw-r--r-- 1 fielding wheel 14438560 Aug 28 09:13 080427-090412-sim_HDR_4rlks.int [Abruzzo/d079/int_080427_090412] fielding% ls -l 080427-090412_4rlks.cor -rw-r--r-- 1 fielding wheel 14449920 Aug 28 09:14 080427-090412_4rlks.cor
The SNAPHU program checks the lengths and quits if it finds they are different. I added some code to the snaphu.pl script to fix this by removing the extra line, but it depends on the LENGTH being correct in the .cor.rsc file. If you add one to the LENGTH in the "n"rlks.cor.rsc file, then the scripts should remove the extra line. You should restart the processing at the "done_filt" step: process_2pass_master $date1_$date2.proc done_filt
It would be better to fix the program that takes the looks, but nobody has spent the time to find out why it produces the extra line.