Open yuankailiu opened 1 year ago
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 @ymcmrshttps://github.com/ymcmrs,
The correction from ICAMS assumes altitude levels starting from -200 m, and going upward to 40 kmhttps://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 mhttps://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 mhttps://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 websitehttps://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 GitHubhttps://github.com/ymcmrs/ICAMS/issues/6, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFQZYFES2BQQI7AAUCTBEKDXXU2GTANCNFSM6AAAAAA4CE3UGU. You are receiving this because you were mentioned.Message ID: @.***>
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.
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!
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!