Generated RSLCs are empty

LiCSAR Processing
1

Pedro: Hi again the frame 130A_09032_111110 https://gws-access.jasmin.ac.uk/public/nceo_geohazards/LiCSAR_products.public/130/130A_09032_111110… has missing burst? Can you help me that I’m correct or no to run again please thanks. Also I see that there are other frame 131A_08951_131513 above 130A_09032_111110 Thanks.

image
image800×603 119 KB

2

hi. ok, there are few possible reasons why missing bursts can happen - this is primarily due to SLC data not available, i.e. issues with autodownloader. But as you show, there is data coverage in the area.

Coming to mind is the location that passes equator (ANX), thus some bursts are from 130A while others from 131A. Despite this is solved in our database (130A frames can contain 131A* bursts and matching bursts during SLC zip ingestion to the database), something is still missing. let’s first visualize the state:

import framecare as fc
import lics_vis as lv

frame1='130A_09032_111110'
frame2='131A_08951_131513'

burstlist = fc.lq.sqlout2list(fc.get_bidtanxs_in_frame(frame1))
burstlist += fc.lq.sqlout2list(fc.get_bidtanxs_in_frame(frame2))
fig = lv.pygmt_plot_bursts(burstlist, [frame1, frame2],
                           background=False, label_nofiles=True)

image
image526×605 15.6 KB

this shows numbers of epochs per burst for frame bursts as ingested to the database - it is strange the central area has very few epochs. let’s check further, compared data in our database so far with the CDSE/ASF:

# get files of those frames as ingested in the database
files=fc.get_frame_files_date(frame1,dt.datetime(2026,2,13), only_file_title=True)
files+=fc.get_frame_files_date(frame2,dt.datetime(2026,2,13), only_file_title=True)

# get files over this area from CDSE/ASF:
import s1data as s1
import datetime as dt
# see help first:
help(s1.get_images_for_footprint)

bidsgpd = fc.bursts2geopandas(burstlist)
hull = bidsgpd.geometry.union_all().convex_hull
footprint = hull.wkt

# (note this below will also check for 131A automatically)
alldata = s1.get_images_for_footprint('130A', footprint,
    startdate=dt.date(2026, 2, 12),
    enddate=dt.date(2026, 2, 14))

for f in alldata:
    if f not in files:
        print(f)

Ok, so we identified all existing files - what is wrong then.. perhaps different burst IDs? let’s check, visualizing the burst coverage first:

filebursts = []
for f in files:
     filebursts += fc.sqlout2list(fc.get_bursts_in_file(f))

lv.pygmt_plot_bursts(filebursts, [frame1, frame2],
                            background=False)

ok.. checking contents of burstlist and filebursts, we can see the culprit: burst misidentification! instead of 131_IW1_59019, we have 130_IW1_59019 …

but some files use 130_IW1_59019 .. we need to merge them into one, only then the system will properly identify them for the next epochs.

The fix can be done using:

fc.check_and_fix_all_bursts_in_frame(frame1)
fc.check_and_fix_all_bursts_in_frame(frame2)

# this above would work, but for the record, i used following instead:
for f in filebursts:
     try:
         fc.check_and_fix_burst(f, framebursts)
     except:
         print('error for '+f)

# now this looks (much) better:
fig = lv.pygmt_plot_bursts(burstlist, [frame1, frame2],
                            background=False, label_nofiles=True)

Fine. this is fixed and should not return.
Further improvement: merging the two frames to one larger one (i.e. 131A_08979_171816) - I first deleted the old ones (to trigger rebuild of volcano subsets) using remove_frame_from_lics.sh and then just ran licsar_initiate_new_frame.sh 131A_08979_171816 20240903

Please use this frame instead..