Runoff spreading - #145
Conversation
|
Example output in /g/data/tm70/as2285/making_inputs/om3-scripts/mesh_generation/25km_remap_weights.nc |
|
And data in /g/data/tm70/as2285/payu/om3_rofl_spread/MC_25km_jra_iaf_spread/archive |
| old_area = area[col] | ||
| new_area = area[row] | ||
| # Exponential weights | ||
| w = np.exp(-dist_N[spread_i] / FOLD) |
There was a problem hiding this comment.
@anton-seaice I think there is a units issue in the decay calculation here:
w = np.exp(-dist_N[spread_i] / FOLD)
Because the tree uses metric="haversine", dist_N is returned as an angular distance in radians. It is then divided directly by FOLD = 15, with no conversion to kilometres.
I checked this against the generated 25 km weights file as well. The 75 destination cells are roughly 125–345 km away, corresponding to about 0.020–0.054 radians. Using the current calculation gives decay factors of around 0.997–0.999, which matches the almost-flat weights in the file. The weights therefore vary by only about 0.2% and the runoff is being spread nearly uniformly rather than noticeably decaying with distance.
Could we convert the haversine distances to a physical unit before applying the decay, and make the unit of FOLD explicit?
| k=SPREAD_N, | ||
| return_distance=True, | ||
| ) | ||
|
|
There was a problem hiding this comment.
Could we guard against meshes with fewer than SPREAD_N eligible ocean cells here?
dist_N, i_N = mask_tree_spread.query(
in_coords_rad,
k=SPREAD_N,
return_distance=True,
)
Perhaps use min(SPREAD_N, number_of_target_cells) and carry that effective value through the downstream array allocations and loops.
| weights_ds["S"] = xr.DataArray(data=S, dims="n_s") | ||
|
|
||
| # Remove zero weights | ||
| weights_ds = weights_ds.where(weights_ds["S"] != 0, drop=True) |
There was a problem hiding this comment.
This line upcasts col and row from integers to float64, because where() temporarily inserts NaN values. The generated weights file confirms both variables are stored as floats.
Since col and row are ESMF indices, could we keep or cast them back to integer after filtering?
2 participants
This generates runoff spreading weights as discussed in ACCESS-NRI/access-om3-configs#396
For the 6 large rivers, runoff is spread to nearby ocean cells with exponentially decaying weights.
Everywhere else, runoff if mapped to closest ocean cell only
Contibutes to #142