casegen error when supplying ij indices

[hertneky]

When running casegen using LAM data, @egrell discovered that the UFS_case_gen.py script fails if providing ij indices. The same failure also exists when using global RTs.

The issue is main() calling find_loc_indices_UFS_history(), which only has logic to find the indices nearest to the provided lon/lat point, hence why latitude/longitude are not subscriptable, since we are only providing ij. On the other hand, find_loc_indices_UFS_IC does have logic to handle either provided lon/lat or indicies. Can this similar logic be added to the problematic subroutine?

Note, the ensemble wrapper script does not even have an option for providing ij.

Example command:
./UFS_case_gen.py -ij 142 69 -d 20210322060000 -i /scratch1/BMC/gmtb/Tracy.Hertneky/ccpp/case_gen/ufs/control_c48_intel_1h/INPUT -g /scratch1/BMC/gmtb/Tracy.Hertneky/ccpp/case_gen/ufs/control_c48_intel_1h/INPUT -f /scratch1/BMC/gmtb/Tracy.Hertneky/ccpp/case_gen/ufs/control_c48_intel_1h -n test_ij_rt -t 5

Error:

Traceback (most recent call last):
  File "./UFS_case_gen.py", line 3773, in <module>
    main()
  File "./UFS_case_gen.py", line 3688, in main
    (hist_i, hist_j, hist_lon, hist_lat, hist_dist_min, angle_to_hist_point, neighbors, dx, dy) = find_loc_indices_UFS_history(location, forcing_dir, lam)
  File "./UFS_case_gen.py", line 506, in find_loc_indices_UFS_history
    dist[i,j] = haversine_distance(latitude[i,j],longitude[i,j],loc[1],loc[0])
TypeError: 'NoneType' object is not subscriptable

[hertneky]

@egrell Was advised to use --location (and --use_nearest if applicable) to get the specified column for now.

[grantfirl]

When running casegen using LAM data, @egrell discovered that the UFS_case_gen.py script fails if providing ij indices. The same failure also exists when using global RTs.

The issue is main() calling find_loc_indices_UFS_history(), which only has logic to find the indices nearest to the provided lon/lat point, hence why latitude/longitude are not subscriptable, since we are only providing ij. On the other hand, find_loc_indices_UFS_IC does have logic to handle either provided lon/lat or indicies. Can this similar logic be added to the problematic subroutine?

Note, the ensemble wrapper script does not even have an option for providing ij.

Example command: ./UFS_case_gen.py -ij 142 69 -d 20210322060000 -i /scratch1/BMC/gmtb/Tracy.Hertneky/ccpp/case_gen/ufs/control_c48_intel_1h/INPUT -g /scratch1/BMC/gmtb/Tracy.Hertneky/ccpp/case_gen/ufs/control_c48_intel_1h/INPUT -f /scratch1/BMC/gmtb/Tracy.Hertneky/ccpp/case_gen/ufs/control_c48_intel_1h -n test_ij_rt -t 5

Error:

Traceback (most recent call last):
  File "./UFS_case_gen.py", line 3773, in <module>
    main()
  File "./UFS_case_gen.py", line 3688, in main
    (hist_i, hist_j, hist_lon, hist_lat, hist_dist_min, angle_to_hist_point, neighbors, dx, dy) = find_loc_indices_UFS_history(location, forcing_dir, lam)
  File "./UFS_case_gen.py", line 506, in find_loc_indices_UFS_history
    dist[i,j] = haversine_distance(latitude[i,j],longitude[i,j],loc[1],loc[0])
TypeError: 'NoneType' object is not subscriptable

@hertneky I think that this is pretty easily fixable. I think that we need to change the order of the find_loc_indices_UFS_history() and find_loc_indices_UFS_IC() calls. This is necessary because the i,j indices are valid on the native grid, not the history file grid. Once the lat/lon corresponding to the i,j indices are found for the IC grid, they can be passed into the find_loc_indices_UFS_history() routine and everything should work. I can make these modifications and submit a PR to restore this functionality.

[hertneky]

@egrell We were curious about the reason being using i,j indices initially with your case generation as opposed to lat/lon, which is usually the more popular choice. Do you think it would be useful in any way to extend the i,j specification to the ensemble wrapper script (UFS_forcing_ensemble_generator.py), which currently supports lists of lat/lon points, ranges of lat/lons, and a file with lat/lons listed. We could implement similar functionality in the wrapper script for i,j if it would be useful.

[egrell]

I was just trying to ensure that I got the exact points that I wanted from the 3d model, as I was running with 3km resolution so the lat/lon needed several decimal places to get the exact location. Obviously, I could have just retrieved the lat and lon of that point and entered that, which is what I ended up doing. I think that it could be useful in the UFS_forcing_ensemble_generator.py, although I didn't use that wrapper with the lam input as it wasn't clear that all the required options were available, based on the User Guide. Honestly, I think the main issue is that the User Guide states that ij indices are an option. I can work with just lat/lon, but then it would be very helpful if the User Guide would be corrected.

…

On Fri, Dec 20, 2024 at 12:30 PM Tracy Hertneky ***@***.***> wrote: @egrell <https://github.com/egrell> We were curious about the reason being using i,j indices initially with your case generation as opposed to lat/lon, which is usually the more popular choice. Do you think it would be useful in any way to extend the i,j specification to the ensemble wrapper script (UFS_forcing_ensemble_generator.py), which currently supports lists of lat/lon points, ranges of lat/lons, and a file with lat/lons listed. We could implement similar functionality in the wrapper script for i,j if it would be useful. — Reply to this email directly, view it on GitHub <#531 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADMPXGNIRI72KQDARJVU5NL2GRV3NAVCNFSM6AAAAABQGLGWHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJXGYYDGOBZGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[grantfirl]

@egrell @hertneky See #549 for a fix for this issue.