Git Product home page Git Product logo

cryotools / osaris Goto Github PK

View Code? Open in Web Editor NEW
50.0 6.0 23.0 3.46 MB

Scripts to facilitate parallel InSAR processing and analysis of Sentinel-1 time series on HPC clusters based on GMTSAR and Slurm.

Home Page: https://cryo-tools.org/tools/osaris/

License: GNU General Public License v3.0

Shell 98.16% Python 1.84%
sar sentinel-1 interferometry slurm high-performance-computing timeseries-analysis

osaris's Introduction

OSARIS

Open Source SAR Investigation System

OSARIS provides a framework to process large stacks of Sentinel-1 Synthetic Aperture Radar (SAR) data in High Performance Computing (HPC) environments.

Table of Contents

Introduction

With the advent of the two Sentinel 1 satellites, high-quality Synthetic Aperture Radar (SAR) data with high temporal and spatial resolution became freely available. This provides a promising framework to facilitate broad applications of detailed SAR- and interferometry- based surface change and motion timeseries. OSARIS aims to provide a toolkit to process large stacks of SAR secenes in parallel on HPC clusters to foster analysis of such extensive datasets. The idea behind OSARIS is to join the benefits of high-performance C programs with parallelization, flexibile processing schemes, and straight-forward configuration, by combining GMTSAR with the workload manager Slurm in a shell-script-based open and modular system.

Key features of OSARIS are:

  • Convenient configuration (only one main config file, documented templates for all configuration)
  • Modular structure for flexible processing schemes, modules for a variety of tasks readily available
  • Minimalist software requirements (bash, csh, GMT, GMTSAR, Slurm)
  • Automatic download of relevant Sentinel-1 scenes based on area of interest (AOI) and time interval
  • Automatic download and assignment of orbits
  • Merging of multiple swaths
  • Merging of bursts from multiple slices, omission of bursts that are outside the AOI
  • Single-master and pair-wise processing schemes
  • Clear and simple directory structure and file naming
  • Output files in the form of analysis-ready geocoded stacks of grid files, optionally cut to AOI extent
  • Processing time measurements (wall clock versus total processing time)
  • Detailed report and log files
  • Summary PDF showing key processing results for each time step (see module Summary PDF)

Setup

Requirements

  1. A working installation of GMTSAR
  2. A working SLURM environment, further info and installation instructions at https://slurm.schedmd.com/
  3. ImageMagick (optional, required only by the 'Summary PDF' module)

OSARIS can also be used in cloud computing environments that support SLURM:

Installation

Just clone the OSARIS repository to your machine:

git clone https://github.com/cryotools/osaris.git

Initial configuration

  • Provide DEM data. You may use the DEM generator kindly provided by Scripps Institution of Oceanography at the University of California, San Diego.

  • In the OSARIS folder, copy configuration templates to config folder

cp ./templates/config.template ./config/*<my_study>*.config
cp ./templates/GMTSAR.template ./config/*<GMTSAR_my_study>*.config
  • Edit new config files to fit your needs and local configuration. See comments in template files for details.

  • Make sure .sh files in root and lib directories are executable. If not, use

chmod +x <filename>

Launch

Go to the OSARIS folder. Launch your run with

./osaris.sh ./config/<my_config>.config

Tutorial

If you are new to Sentinel-1 processing, take a look at the OSARIS Tutorial at CryoTools.org that will guide you through an example, starting from the very basics of finding data.

Tipps

  • Launch OSARIS from within a tmux or screen session to detach your terminal session from the process. Doing this will prevent the OSARIS processing to fail in case you lose connection, your terminal crashes, etc. Tmux' feature to arrange multiple windows and panes is extremely handy to monitor log files during processing (see below).

  • Start with relatively few scenes and a minimum of modules. Check the output and optimize your configuration. When the basic processing results fit your needs, use the options to turn off pre- and interferometric processing and start adding modules.

  • Keep an eye on the log files during processing. In your procesing directory, use

tail -f Log/_logfile_name_

to monitor what is going on.

  • After processing, take a look at the reports in 'Output/Reports'.

  • Use the 'summary_pdf' module to get an overview of the interferometric processing results.

  • Make sure the DEM extent is not much bigger than the extent of the scenes you actually want to process. A big DEM will need a lot of extra processing time.

Modules

Concept

Modules allow to execute additional processing routines at different stages, i.e. after file downloads, after file extraction, after GMTSAR processing, and after post-processing (more module hooks may be added in the future). As such, OSARIS modules facilitate designing processing schemes that fit individual needs while keeping the core code as compact as possible.

In order to execute a module, go to the 'MODULES' section in the config file and put the module name (i.e. the name of the subdirectory of modules/) into the array of the adequate hook. For example, if you would like to execute 'Stable Ground Point Identification', 'Harmonize Grids', and 'Summary PDF' after GMTSAR interferometric processing, this would be:

post_processing_mods=( SGP_identification harmonize_grids summary_pdf )

When multiple modules are allocated at one hook the modules will be executed in the same order they appear in the array. Most modules require a config file; A template configuration should be in templates/modules-config which must be copied to the config directory for the module to work:

mv templates/module-config/<module_name>.config.template config/<module_name>.config

Available modules

Crop

Cut geocoded grids to extend given min/max longitude/latitude coordinates. Call: crop Status: beta

Displacement

Convert unwrapped phase (radians) to line-of-sight displacement (mm) Call: displacement Status: beta

Detrend

Remove large-scale trends from grid stacks using polynomial surfaces, cf. GMT grdtrend. Call: detrend Status: beta

GACOS correction

Correct interferogram time series for atmospheric delays of the SAR signal using GACOS data. Call: gacos_correction Status: beta

Grid Difference

Calculate the difference between OSARIS result grid files throughout the timeseries. Call: grid_difference Status: beta

Harmonize Grids

Shift grid files relative to 'stable ground points'. Typically used to harmonize time series of interferograms and LOS displacement files. Call: harmonize_grids Status: beta

Ping

Wake up sleeping nodes. Call: ping Status: beta

Stable Ground Point Identification

Identify stable ground points based on consitently high coherences throughout the time series. Call: sgp_identification Status: beta

Statistics

Calculate statistics for a series of grid files. Call: statistics Status: beta

Summary PDF

Preview key processing results in a single graphic overview. Requires ImageMagick. Call: summary_pdf Status: beta

Timeseries xy

Extract values for particular coordinates throughout a series of grids (e.g. coherence, phase). Call: timerseries_xy Status: beta

Unstable Coherence Metric

Identify regions where high coherence values drop substantially between two data takes. Call: unstable_coh_metric Status: beta

Module development

The easiest way to get started developing your own OSAIRS module is by copying the template files prepared for this purpose:

# In each line, replace <my_new_module> with your module name
cp -r modules/__module_template__ modules/<my_new_module>
mv modules/<my_new_module>/__module_template__.sh <my_new_module>.sh 
cp templates/module-config/__module_template.config.template config/<my_new_module>.config

Many typical processing steps are implemented in the existing modules, copy as much as you can. When your module works and you think it might be useful to others please get in touch or create a merge request from a forked copy.

The following constants will be set by the OSARIS main program upon initialization and are available in all modules that get included:

Constant Value
$OSARIS_PATH Full path to the directory from which OSARIS was launched.
$work_PATH Full path to the Processing directory.
$output_PATH Full path to the Output directory.
$log_PATH Full path to the Log directory.
$topo_PATH Full path to directory with dem.grd used by GMTSAR.
$orbits_PATH Full path to directory containing the orbit files.

All values set in the main config file can be accessed by their respective variable name.

Contributing

Your participation in the development of OSARIS is strongly encouraged! In case you want to add a feature, module, etc., please fork your copy, code your additions, and open a merge request when finished. If you are using OSARIS, it would be very helpful if you could prepare a short report with general information about your OS and hardware setup and your experience with the software, so that we can evaluate compatibility over different configurations. For all reports and inquiries please contact David Loibl.

Crediting OSARIS

As stated in the license file, you are free to use OSARIS in whatever way you like. If you publish OSARIS results, e.g. in scientific publications, please refer to the OSARIS method paper in Frontiers in Earth Science.

In addition, we encourage adding a reference to the version of OSARIS you have used for processing using the respective Zenodo DOI:

DOI

Credits / Contributors

A (hopefully) full list of contributors is available in doc/contributors.md - Many thanks to all those who have contributed to make this a better tool. Many thanks to Bodo Bookhagen and Ziyadin Cakir who substantially supported the conception of OSARIS with thoughtful comments and by sharing scripts. The work of David Loibl on OSARIS was supported by the Research Network Geo.X during 2016-12 - 2017-12 within the scope of the project MORSANAT.

osaris's People

Contributors

david-loibl avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

osaris's Issues

Move data preparation to SLURM job

Make a SLURM job for data preparation instead if processing on the login node. - Add specific SLURM configuration options (1 job, short processing, much ressources) - Use check_queue.sh to monitor job status - Start subsequent processing steps when finished

UCM: add option to identify positive coherence changes

In the current concept, UCM detects only locations where coherence dropped from high to low values. However, it may also be interesting to detect locations where coherence substantially increased. For instance, material displaced by a rockfall event would lead to a substantial increase in coherence if deposited in a place where low coherence prevailed to this point, such as a forest.

This may be optionally activated in the config file. Increasing coherence may be indicated by negative values in the resulting file, so that UCM results would have a value range from -1 to +1.

Add single master mode

Add a new processing mode that uses only one scene as master and calculates a time series of deviations from the master scene. Identify potential to resolve permanent scatteres.

Strip bursts

It should be possible to remove bursts which are not relevant for processing. In the config file a range of bursts to consider in processing should be included, parallel to the selection of swaths.

Module config in subdirectories

The current concept in which all config files are stored in one directory can be very inconvenient when working on multiple projects at the same time. Specifically, module config files need to be changed each time when a new run for a different study area is started, even though the configuration for individual modules will remain the same for each study area in most cases.
Therefore, the module config files should be saved to subdirectories of $OSARIS_PATH/config and the path to this module config directory should be a parameter in the main config file of a project.
This will require to modify the check for config files in all modules.

Change 'Harmonize Grids' to a generic script instead of module

Grid harmonization must be applied at several stages and to different datasets in many workflows, e.g. when using the GACOS module. There, it would be more convenient to transform the module into a generic script that takes input and output directory as well as reference point location as input.

Check matching orbits more thoroughly

The current orbit matching routine may return false positives when the orbit library is incomplete. An additional check regarding the end date of the orbit file is required to verify that the scene is actually covered by the orbit data.

Automatically merge swaths and cut to AOI

After interferogram generation, all swaths should be merged, so that only one set of files per scene pair is stored in the output directory.

GMTSAR's merge_swath should do the job:

USAGE: merge_swath inputlist output [stem]
inputlist example:
F1/intf/2015036_2015060/S1A_20150609.PRM:F1/intf/2015036_2015060/phasefilt.grd
F2/intf/2015036_2015060/S1A_20150609.PRM:F2/intf/2015036_2015060/phasefilt.grd
F3/intf/2015036_2015060/S1A_20150609.PRM:F3/intf/2015036_2015060/phasefilt.grd
note: use the slave PRM which contains the shift information
output: output.grd [stem.PRM]
note: please put the files to stem.in in the order of swath numbers.
make sure all images have same num_rng_bin

Subsequently, the output grids should be cut to an AOI defined in the config file to avoid huge files.

Set Fwd-Rev-Unwrapping Sum to zero at PSI coords

Whole interferograms are occasionally marked as invalid owing to full-scene shifts in unwrapping of either fwd or rev pairs. To avoid this, set both fwd and rev interferograms to zero at PSI coords when these exist.

Other sensors

Add other sensors. Minimum TSX, optimum all from GMTSAR website.

Consistent naming for output files

All output grid filenames shall have the dates in the first part, followed by a sequence of identifiers for processing steps applied to it in the form
YYYYMMDD--YYYYMMDD-corr_ll-module1-module2.grd

Buffer overflow in SBAS processing

The following SBAS call ...
xdim=$(gmt grdinfo -C unwrap.grd | awk '{print $10}') ydim=$(gmt grdinfo -C unwrap.grd | awk '{print $11}') n_int=$(wc -l < intf.tab) n_scn=$(wc -l < scene.tab) sbas intf.tab scene.tab $n_int $n_scn $xdim $ydim -smooth 1.0 -wavelength 0.0554658 -incidence 30 -range 800184.946186 -rms -dem
results in this error:

mode --> 2

compute RMS misfit
compute DEM error

setting smoothing to 1.000
setting radar wavelength to 0.055 m
setting radar incidence angle to 30.000 degree
setting range to 800184.946 m
Memory Allocation Successful...
read table file ...
number of SAR scenes is 4
number of interferograms is 4
read phase and correlation grids ...
*** buffer overflow detected ***: sbas terminated
======= Backtrace: =========
/usr/lib64/libc.so.6(__fortify_fail+0x37)[0x2ac567943077]
/usr/lib64/libc.so.6(+0x10d230)[0x2ac567941230]
/usr/lib64/libgmt.so.5(gmt_grd_get_format+0x4d8)[0x2ac5639e57b8]
/usr/lib64/libgmt.so.5(gmtlib_read_grd_info+0x1d)[0x2ac5639e5a9d]
/usr/lib64/libgmt.so.5(+0x4ecfc)[0x2ac5639bacfc]
/usr/lib64/libgmt.so.5(GMT_Read_Data+0x203)[0x2ac5639bb513]
sbas[0x404c4e]
sbas[0x401cba]
/usr/lib64/libc.so.6(__libc_start_main+0xf5)[0x2ac567855b35]
sbas[0x4016d9]
======= Memory map: ========
[...]

Automatic cleanup option

Add option to cleanup the folders to save disk space: - remove Processing/raw/ - remove Processing/orig/

Automatic detection of relevant swaths

In the prepare-data.sh routine, the swath relevant for processing the area of interest should be determined automatically. This will render the manual input in the config file obsolete.
Envisioned work flow:

  • Read the orbit direction from S1 annotation XML file:
    grep 'pass' s1a___.xml | tr '<' ' ' | tr '>' ' ' | awk '{print $2}'
  • Check if range values are out beyond range range (i.e. < 0, > max) using SAT_llt2rat for each swath
  • Add all swaths necessary to process the whole AOI

Module 'Change Detection'

Goal: determine regions of (a) general high stability, (b) general instability, and (c) stable regions with instable events.

  • Create pairwise coherence diffs
  • Calculate mean coherence and variance throughout the timeseries for each pixel
  • From variance, identify region

Combine analysis of coherence/coherence diffs with l.o.s. displacement (and maybe others?).
Extract subareas (e.g. glaciers + buffer) and analyze these in detail.

Summary file

Add the option to create a summary file after finishing the processing which summarizes the results. The summary file should contain for each pair: - Intf preview - Cohernece preview - Unwrapping forward/reverse difference [opt, when processed] - Days between scenes - Some basic statistics

These info should be arranged horizontally, one row for each pair.

In addition, coherence differences between two pairs may be added between two rows if these were processed as well.

Basic output should be HTML, optionally convert to PDF.

'Ping' module

Add a module that sends minimal 'ping' batch jobs to the queue to wake up sleeping nodes.

Mask grd files by threshold

Add a generic script to mask grid files by a threshold.
Parameters should be

  • Input file
  • Threshold value
  • Operator (GE, GT, EQ, LE, LT)
  • Output file

Use GMT grdmath to set all values higher/equal/lower than the threshold to NaN.

Modules

Add hooks to include modules after each processing step.
Prepare a common design/template for modules that facilitates as much automation of module integration as possible.
In the config file, the activation of a module should be limited to one parameter, e.g. 'acitvate_change_analysis=1".

Process scenes from multiple orbits and slices

This will require a modification of the Processing and Output directory structure.

The orbit and slice of each scene can be obtained from its manifest.safe:
[...] <safe:relativeOrbitNumber type="start">107</safe:relativeOrbitNumber> [...] <s1sarl1:sliceNumber>4</s1sarl1:sliceNumber> [...]

Mask grd files by polygon

Create a generic script to mask GMT grid files by a polygon provided in a .gmt or .shp file.
Parameters:

  • Input grd file
  • Polygon file
  • Mask inside / mask outside
  • Output grd file
  • Buffer (optional, default 0)

Use GMT grdmask to create a mask grid. Subsequently, use GMT grdmath with the 'INSIDE' operator to set data points inside/outside the mask area to NaN.
Shapefiles should be feasible input polygon files as well and automatically converted to .gmt files with to GDAL ogr2ogr (cf. routine in module 'Create Summary Report').

Download only orbits needed for specific processing task

This will require a list of available orbits from which the files actually needed can be determined. Only these orbits shall then be downloaded and used for further processing.

Will substantially reduce downloads and required HD capacity in cases where only few specific scenes are processed.

Ascending and descending orbits in the same run

Envisioned work flow:

  • All scenes for the area and time frame of interest are downloaded (no restriction by relative orbit in config)
  • All scenes are extracted to Processing/orig
  • The prepare-data.sh routine identifies the pass direction and creates lists of asc/dsc files
  • Files for each pass direction are processed separately (raw-asc, raw-dsc)
  • Results are brought back together in the Output directory where each pair is identified by date

Output directory structure

Make the output directory structure more convenient.

/Pairs-forward

  • Amplitudes
    • preview (png, kml, ps)
  • Coherences
    • preview (png, kml, ps)
  • Interferograms
    • preview (png, kml, ps)
  • Interferograms-unwrapped
    • preview (png, kml, ps)
  • LOS-displacements
    • preview (png, kml, ps)
  • ...

/Harmonized-interferograms
/Stable-ground-point
...

Radar coordinate data does not need to be copied to the output directory.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.