swot hr simulator and vegetation module · swot hr simulator and vegetation module swot sdt...

SWOT HR simulator and vegetation module

SWOT SDT meeting, Toulouse, July 2015, 7

D.Blumstein, C.Ruiz, C.Lion, S.Biancamaria, F.Niño, N.Estival

Vegetation module – Development status

Work about reliability� Test with many cases (real scenes) with different vegetation situations� Better management of errors, protections against invalid data� Complex cases with high resolution data

Latest release:� Binary module

� compute interferogram resulting from a soil covered by vegetation or bare soil� same interfaces and behavior as the JPL binary « makeInterferogram »� add 4 parameters to the landtype characteristics to define the vegetation

» Height, volumic backscatter, extinction coefficient, gap fraction

� Gap fraction� Breakpoints


Gap Fraction implementation

� The vegetation module, as it is implemented today, allows taking into consideration a Gap fraction parameter for a vegetation stand. This parameter has been introduced in order to consider vegetation stand that could be seen with gaps from above (soil visible through gaps within the vegetation). � Giving the fact that the SWOT mission incident angles (~0.5° to 5°) are close to nadir this may be the case most of

the time when acquiring images over vegetated areas

� The main advantage of using a parameter such as the gap fraction implemented analytically is to avoid generating a vegetation stand with geometrically defined gaps.� Indeed, this could be very difficult for the vegetation stand generation (a randomly generated “comb“ profile along the

ground range direction) and will induce a loss in speed.


Gap Fraction approximation validation

� In order to validate our analytical approach of the gap fraction we have to compare with the “real” case of a vegetation profile (comb profile) with the same gap fraction level


hσv

σe

ΞhGap fraction : Gf

σeff

Gap fraction : 0.5 or (50%)

Gap fraction : 0.66 or (66%)

?


� Full vegetation areas would be enough

� Only one azimuth interferogram line over vegetation area

� The GDEM used is over a flat surface area (land).

� Ground spacing of 1 m � to be able to get a representative numbers of gap-vegetation transitions encompassing a range gate


Range gate for 5° incidence

Range gate for 0.5° incidence


� The current version of the vegetation module does not account for shadow generated by the vegetation

� This has been decided because of the very near-nadir incident angle configuration. SWOT will not be concerned with shadows

� However, when trying to simulate a high density vegetation comb with the purpose of the validation of the analytical gap fraction approach this case may arise and simulation results in term of coherence or elevation derived from the interferometric phase will certainly not match.


Range gate

Shadow region

Extinction through the

vegetation not accounted

for



Case Hv = 30 m, σext = 1.04 dB/m, σv = -5 dB and bare soil σ0= -17 dB



Case Hv = 5 m, σext = 0.5 dB/m, σv = -5 dB and bare soil σ0= -17 dB

dsl


Zone of interest to study layover from vegetation

sdl


FR NR

Vegetation on a near-flat river bank

River bank vegetation height : 5 m


NR FR NR FR

Elevation error

over the river mask (m)Coherence

over the river mask

σ0water = 15 dB, σ0land = - 8 dB,

σ0veg = - 5 dB (m2.m-3)

Veg. extinction = 0.1 dB/m

River bank vegetation height : 15 m


Elevation error

over the river mask (m)

Coherence

over the river mask

σ0water = 15 dB, σ0land = - 8 dB,

σ0veg = - 5 dB (m2.m-3)

Veg. extinction = 0.8 dB/m

Sam : a glue between users and the JPL binary modules

� Why ? � Help to make the learning curve less stiff

» Some good feedback from users (LEGOS, CERFACS, CNES, M2C)

� How ?� Ready to use chains

» Run without user intervention once the (minimal set of) data are provided» Use of the default data mechanism provided in the JPL binary modules» Given with one simple and quick test case that is known to run without problem

� Graphs (quick-look) that help to detect errors in the input data� Complementary tools (Near Range computation, conversion of DEM or Landtype to the

format required by JPL binary modules, …)

� CNES agreed on distribution to SWOT scientists through a license agreement� Sam framework, chains and modules, vegetation module, swothr tools� License

» Sam, chains and modules (written in python) distributed as source code» Authorization to modify but not to redistribute

� Prerequisite: obtain the JPL binary modules which are not includedSWOT SDT meeting, Toulouse, July 2015, 713

Two main chains


select_orbit : � 2 predefined chains withsimple inputs� DEM� Landtype + water height� Default data that can be

overwritten

� select_orbit� Run once for a given

Region Of Interest� Compute Pass Plan

� makeWaterData_classif� Run for each pass of

SWOT in the period

makeWaterData_classif:

� Other smaller chainsare available

Outputs of the select_orbit chain

� SWOT footprint over the Region Of Interest

� Pass Plan


# Mission start: 2014-01-01 00:00:00# Simulation start: 2015-04-01 00:00:00# Simulation stop: 2015-05-01 00:00:00##run cycle pass MissionTime year DayOfYear date timec022_t045 22 45 39794780 2015 96.58773 2015-04-06 14:06:20c022_t323 22 323 40652885 2015 106.51950 2015-04-16 12:28:05c022_t394 22 394 40873614 2015 109.07424 2015-04-19 01:46:54c023_t045 23 45 41597426 2015 117.45169 2015-04-27 10:50:26

Some of the « quick looks » automatically available


� Main objective : check that the simulation has been successful

Quick looks dedicated to the analysis of height errors

� Warning : errors at the native instrument pixel resolution

� Will be reduced (averaging) whencomputed at the spatial resolutionof the SWOT mission requirements


total error error due to instrument noise error due to layover

Comparison of the point cloud with the land type map


Main features of sam

� Developed for Linux (tested on debian, Ubuntu and also Mac OSX)

� No pretty GUI. This is a Command Line Interface� But online documentation in html (same form as the python documentation)

� Transparent implementation� Work space for each simulation is a directory with one subdirectory for each module� Work space of the modules has 2 subdirectories : inputs and outputs

� Can be run with the same commands on a simple computer or a cluster� Parallelism internal to the chain is used when possible (on multi core)� On a cluster, the language for job control is used (under the hood, user don’t need to know)

» PBSPro supported, other could be added if needed

� Implementation of multitemporal simulations� Pass Plan can be used to run automatically multiple simulations once the definition of the

scene has been computed for each pass of SWOT (landtype map and water height)� On a cluster, these simulations are run in parallel� New. Not yet heavily testedSWOT SDT meeting, Toulouse, July 2015, 719

Functions for developing

� Developing� Modify and/or add new chains� Modify and/or add new modules

� Thought as multi users from the beginning� Reference catalog of chains and modules accessible by all the members of the project� Local catalogs is for code under development and test

» Usable by the developer» Can also be shared with some collegues (e.g. for test purpose before publication)

� Once tested, the local modules or chains can be made available to the other membersof the project through a publication (under administrator control)

� Reference catalogs are under configuration control� Documentation can be modified by everybody without restriction

» Written in a simple markup language (rst)» Under configuration control

� Plans to include new modules developed in the frame of the ADT


swot hr simulator and vegetation module · swot hr simulator and vegetation module swot sdt...

Documents