Altitude interpolation grids

[yuankailiu]

Hi @ymcmrs,

The correction from ICAMS assumes altitude levels starting from -200 m, and going upward to 40 km.

In addition, whenever the altitude is below -200 m, it is set to -100 m. Why do we need this checking and why not set it to just -200 m?

The minimum elevation, for most regions, I guess is alright. But I work on the Dead Sea Valley, where the basin's elevation is around -400 m. This results in NaN values for the ICAMS time series at the pixels below -200 m, as the image shows within the valley between latitude 31 deg and 32 deg. (This image is the apparent velocity field of an ICAMS-generated time-series file, representing the trend of the ERA5 model).

a zoom in at the valley where weird values occur. The water body here is masked out.

Can I simply modify the code and let the altitude grids start from -400 m? Is there anything related that I should be aware of?

Side question, I also saw PyAPS having the same min altitude of -200 m. Is -200 m the lower bound of the ERA5 weather models? Or it is a somehow safe way to set for interpolation? From the ECMWF website it seems like the model are down to the Earth's surface.

Thanks for your help!

[ymcmrs]

Thanks for pointing this out, I did set it from -200m to 40km for the integration/interpolation. Since most of the cases in the world should above -100m, that could be the reason I set it to -100m (not remember clearly). Yes, Dead sea could be the only one or two places in the world that the DEM is less than -200m, and you need to change that threshold (I also did some experiments there couple of years ago with ICAMS). The intelligent way should adjust this based on the DEM automatically. I could modify this soon. From: Yuan-Kai Liu ***@***.***> Date: Tuesday, 29 August 2023 at 9:33 AM To: ymcmrs/ICAMS ***@***.***> Cc: Yunmeng Cao ***@***.***>, Mention ***@***.***> Subject: [ymcmrs/ICAMS] Altitude interpolation grids (Issue #6) Hi @ymcmrs<https://github.com/ymcmrs>, The correction from ICAMS assumes altitude levels starting from -200 m, and going upward to 40 km<https://github.com/ymcmrs/ICAMS/blob/main/icams/tropo_icams_sar.py#L418-L421>. In addition, whenever the altitude is below -200 m, it is set to -100 m<https://github.com/ymcmrs/ICAMS/blob/main/icams/tropo_icams_sar.py#L404-L405>. Why do we need this checking and why not set it to just -200 m? The minimum elevation, for most regions, I guess is alright. But I work on the Dead Sea Valley, where the basin's elevation is around -400 m. This results in NaN values for the ICAMS time series at the pixels below -200 m, as the image shows within the valley between latitude 31 deg and 32 deg. (This image is the apparent velocity field of an ICAMS-generated time-series file, representing the trend of the ERA5 model). [Image removed by sender. image]<https://user-images.githubusercontent.com/55262505/263861679-eb0337e2-d7f9-4c22-a4b6-8abc10486782.png> a zoom in at the valley where weird values occur. The water body here is masked out. [Image removed by sender. image]<https://user-images.githubusercontent.com/55262505/263865438-eae88ff4-1705-4474-a44d-900c93a84655.png> Can I simply modify the code and let the altitude grids start from -400 m? Is there anything related that I should be aware of? Side question, I also saw PyAPS having the same min altitude of -200 m<https://github.com/insarlab/PyAPS/blob/main/src/pyaps3/processor.py#L49>. Is -200 m the lower bound of the ERA5 weather models? Or it is a somehow safe way to set for interpolation? From the ECMWF website<https://confluence.ecmwf.int/display/CKB/ERA5%3A+compute+pressure+and+geopotential+on+model+levels%2C+geopotential+height+and+geometric+height#ERA5:computepressureandgeopotentialonmodellevels,geopotentialheightandgeometricheight-Pressureonmodellevels> it seems like the model are down to the Earth's surface. Thanks for your help! — Reply to this email directly, view it on GitHub<#6>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFQZYFES2BQQI7AAUCTBEKDXXU2GTANCNFSM6AAAAAA4CE3UGU>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[yuankailiu]

Thank you if you can do this. Here also needs to be changed, where the minimum altitude is defined in the utility.

I am still testing my changes, but there are still some errors regarding get_LOS_parameters() in Step 2.

[yuankailiu]

Hi @ymcmrs, I have a question about start_time and end_time in GAMMA, or your start_sar and end_sar in ICAMS want to clarify.

In the ISCE IW1.xml, there are "sensingstart" and "burststartutc". The "sensingstart" refers to UTC time corresponding to first line of burst SLC, and the "burststartutc" is Actual sensing time corresponding to start of the burst. I am confused about which ones I should use for computing the LOS locations and delays ( {seingstart, sensingstop} or {burststartutc, burststoputc} )?

Their values for one specific burst are:
sensingstart 2023-05-24 03:27:40.518828
sensingstop 2023-05-24 03:27:43.628885
burststartutc 2023-05-24 03:28:06.371414
burststoputc 2023-05-24 03:28:07.413693

To get start_sar and end_sar, what I did right now is to use the sensingstart of my first burst and the sensingstop of my last burst. Is it supposed to do it this way?

I have a 39-bursts SLC,
sensingstop of my last burst minus sensingstart of my first burst, I got a total time of 107.906 seconds
burststoputc of my last burst minus burststartutc of my first burst, I got a total time of 105.688 seconds
Results in a difference of total time ~2 seconds though... Not sure which is the right way and does it matter?

For CENTRAL_TIME, I simply take the middle point of start_time and end_time. But the above two ways give me a difference in CENTRAL_TIME of ~0.0035 seconds. Given a satellite velocity of ~7.5 km/s, this means 26 m difference from 800 km height. So maybe does not matter?

Thanks a lot!