Using ESD in dockerized topsApp with ionosphere correction turn-on

[mgovorcin]

Currently, we are not using ESD in our topsApp processing if the ionosphere delay (split-spectrum) computation is on. LINK

The rationale is to avoid doing ESD twice as it can be done also as part of ionosphere computation LINK. However, there are few things to consider:

1. ESD is only performed within iono computation if the option 'considerBurstProperties; is turn on (default is off), which calculates burst azimuth shifts (scalloping effect - burst jump) based on ionosphere layer. Currently, we also have it off.
2. Iono-based burst azimuth shift correction is applied directly to wrapped interferogram (if the option '"apply ionosphere correction" is turn on) after merge_bursts step. I will go back and confirm this.
3. This logic in processing does not apply on our workflow, as we are computing ionosphere delay after the topsApp default run (producing geocoded filt unwrapped phase, coh, and geometry files). Thus, we do not rely on ionosphere azimuth shifts to correct miss- cor-registration before generating geo unwrapped phase. There are two implications with this approach: 1. unwrapped phase will not only be corrected for burst jumps but also for long-wavelength ionosphere delay. 2. quality of long-wavelength iono computation depends on the coherence of lower and upper subband in the area, as well as off existence of unwrapping errors
4. This also implies that we are not using ESD in our processing and rely always only on geometry cor-registration at the moment, which might leave sometimes unwanted scalloping effect (burst misalignment) in GUNW unwrapped phase layer even though there is no significant ionosphere content for C-band.
5. I am not familiar if there are some implications of using ESD with ionosphere correction as iono is using coregistrated SLCs as input. I do not think it should affect it, but would be worthy to check it out