Fix solid earth tides computation fail when frequencyA is missing#243
Fix solid earth tides computation fail when frequencyA is missing#243xhuang-jpl merged 29 commits intoisce-framework:developfrom
Conversation
Tyler-g-hudson
left a comment
There was a problem hiding this comment.
LGTM, just one question for clarification
| wavelength = isce3.core.speed_of_light / \ | ||
| h5_obj[f'{gunw_obj.GridsPath}/frequencyA/centerFrequency'][()] | ||
| # Wavelength in meters; fall back to frequencyB if frequencyA is not found | ||
| for freq in ('A', 'B'): |
There was a problem hiding this comment.
Is there a reason why we capture first available of A or B instead of calculating a different datacube for each? They would have different values, wouldn't they?
There was a problem hiding this comment.
good question @Tyler-g-hudson, for NISAR InSAR processing, we are always processing frequencyA even if the product has both freqA and freqB. This fix is for users who need to process the freqB stand alone.
There was a problem hiding this comment.
Sure, I've understood that part - what I mean to ask is why we have selected to do that when the values might be different between two different data cubes, is it because we only expect people to use it for the primary frequency?
There was a problem hiding this comment.
We always expect people use the frequencyA as the primary at least for the NISAR.
This PR fixes a bug where solid earth tides computation fails when
frequencyAis missing. The logic now falls back tofrequencyBif available, and raises an error if neither exists.