Add in logic to not fail when no HRRR weather model is available

[jacquelynsmale]

Description

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• I have added an explanation of what your changes do and why you'd like us to include them.
• I have written new tests for your core changes, as applicable.
• I have successfully ran tests with your changes locally.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[asjohnston-asf]

FYI, here are the test cases we itemized for this feature:

1. Install RAiDER
   1. git clone git@github.com:dbekaert/RAiDER.git
   2. cd RAiDER
   3. mamba env create -f environment.yml
   4. mamba activate RAiDER
   5. python -m pip install -e .
2. Download the two test input files
   1. aws s3 cp s3://asj-dev/raider/ . --recursive
3. Add a .netrc entry for dataspace.copernicus.eu
   1. machine dataspace.copernicus.eu login *** password ***
4. Run the tests
   1. raider.py ++process calcDelaysGUNW --weather-model {model} --file {file}
   2. "adds data layers" takes 10ish minutes and adds four data layers to the .nc file. Since this edits the file in place, be sure to grab a fresh copy before running subsequent tests
   3. "nothing to do" takes ~3 seconds and doesn’t change the input .nc file
   4. "invalid choice" takes ~3 seconds and doesn’t change the input .nc file
   5. "location is unavailable" takes ~15 seconds and doesn’t change the input .nc file

v0.5.3	HRRR	None	AUTO
S1-GUNW-D-R-071-tops-20241204_20241029-135046-00118W_00042N-PP-5700-v3_0_1.nc	adds data layers	nothing to do	invalid choice
S1-GUNW-A-R-091-tops-20241205_20241123-233558-00074W_00037S-PP-014f-v3_0_1.nc	location is unavailable	nothing to do	invalid choice

New Version	HRRR	None	AUTO
S1-GUNW-D-R-071-tops-20241204_20241029-135046-00118W_00042N-PP-5700-v3_0_1.nc	adds data layers	nothing to do	selects HRRR and adds data layers
S1-GUNW-A-R-091-tops-20241205_20241123-233558-00074W_00037S-PP-014f-v3_0_1.nc	location is unavailable	nothing to do	selects None and nothing to do

[asjohnston-asf]

I think a more complete changelog entry for this feature would be:

Added

• 695 - Added a new AUTO option to the --weather-model argument of raider.calcDelaysGUNW. Selecting this option will automatically select the weather model to use based on the established strategy for standard ARIA S1 GUNW products. The current strategy is to use HRRR where available and None otherwise.

@cmarshak @dbekaert does that communicate our intent well enough? I'm open to keywords other than AUTO if there's one you prefer.

[asjohnston-asf]

There's code that strongly suggests the --weather-model=HRRR was intended to do what we want when run via HyP3. The if block at https://github.com/dbekaert/RAiDER/blob/dev/tools/RAiDER/cli/raider.py#L604-L632 is run for jobs run via HyP3, and the availability checks at L620 and L627 are both intended to exit with a success status code without making any changes to the GUNW product.

However, check_weather_model_availability invoked on L627 raises ValueError on L137 when the scene is outside the HRR's spatial extent (rather than returning False), causing the program to exit with a failure status code. This mismatch between the calling code expecting True/False and the function raising an exception looks like an unintended bug to me.

This is the only place check_weather_model_availability is called. I propose we update the function to return False instead of raising ValueError on L627. Then HyP3 can submit jobs using weather_model=HRRR and we'll get the behavior we want for standard products.

[cmarshak]

Yes - it's honestly, quite confusing because it supports different use cases. Auto seems ok, but there are some nuances that not being considered. The HRRR data is actually not continuous in that sometimes we expect it to be available (because a product is over US CONUS or AK), but the date is not available: https://github.com/ACCESS-Cloud-Based-InSAR/East-Coast-VLM-Sprint/blob/dev/check_hrrr_availability/Check%20HRRR%20CONUS.ipynb. That is, spatially we expect HRRR but temporally it is not available.

The "bug" that @asjohnston-asf you are seeing is the result of having it exit successfully there.

I did a lot of the logic to help, but not sure what the best way to proceed.

ALSO! to keep in mind that eventually "auto" should use the HRES data that is being stored at ASF - this should be implemented at some point.

[cmarshak]

I think a more complete changelog entry for this feature would be:

Added

• 695 - Added a new AUTO option to the --weather-model argument of raider.calcDelaysGUNW. Selecting this option will automatically select the weather model to use based on the established strategy for standard ARIA S1 GUNW products. The current strategy is to use HRRR where available and None otherwise.

@cmarshak @dbekaert does that communicate our intent well enough? I'm open to keywords other than AUTO if there's one you prefer.

I think this makes sense - see my previous comments for the caveats regarding exiting...