Feature/use_hash_indg #295
Conversation
|
replaces pull request #270 |
| @@ -2738,10 +2738,10 @@ subroutine write_smapL4SMaup( option, date_time, work_path, exp_id, N_ens, & | |||
| data_h_9km_tile_8 = real(nodata_generic,kind(0.0D0)) ! init (not in grid2tile!) | |||
| data_v_9km_tile_8 = real(nodata_generic,kind(0.0D0)) ! init (not in grid2tile!) | |||
|
|
|||
| call grid2tile( tile_grid_g, N_catf, tile_coord_f%i_indg, tile_coord_f%j_indg, data_h_9km_grid_8, & | |||
| call grid2tile( tile_grid_g, N_catf, tile_coord_f%hash_i_indg, tile_coord_f%hash_j_indg, data_h_9km_grid_8, & | |||
There was a problem hiding this comment.
I'm pretty sure this should be %i_indg, not %hash_i_indg. Here, we are simply going back and forth between the tile space and the grid that is associated with this tile space. Because this subroutine only works for the EASE grid, and because %i_indg and %hash_i_indg are identical in this case, the results are going to be the same. But we still need to use the appropriate field of the tile_coord_f structure.
| data_h_9km_tile_8 ) | ||
|
|
||
| call grid2tile( tile_grid_g, N_catf, tile_coord_f%i_indg, tile_coord_f%j_indg, data_v_9km_grid_8, & | ||
| call grid2tile( tile_grid_g, N_catf, tile_coord_f%hash_i_indg, tile_coord_f%hash_j_indg, data_v_9km_grid_8, & |
There was a problem hiding this comment.
Same comment as above. Two more such instances follow below.
There was a problem hiding this comment.
I feel we should not cheery-picking but be consistent through out the codes: hash_x_indg is used for computation and x_indg is used to keep the original record whenever we can. The only place we should use X_indg probably is here
GEOSldas/src/Components/GEOSldas_GridComp/GEOSmetforce_GridComp/LDAS_Forcing.F90
Lines 4674 to 4679 in b674b87
There was a problem hiding this comment.
This isn't cherry-picking. For a grid2tile operation, we need to use the i,j indices that are associated with grid that is involved in the operation. Here, the grid is the original grid associated with the tile space, not the "hash" grid used in the perturbations and to support the EnKF analysis. I know this is a bit subtle because it looks like it's part of the EnKF analysis, but it's really just a complicated special case to output (1d array) tile-space fields in gridded (2d array) format (taking advantage of the fact that by construction the EASE-based tile space has at most one tile in each grid cell.)
Again, the grid involved here is NOT the hash grid that is used for perturbations or to support the EnKF analysis.
There was a problem hiding this comment.
It seems it is just part of SMAP writing. Changed
|
The previous comment (by @weiyuan-jiang ) applies to pre-processing. |
- fix of earlier change: tile2grid_full() should use %[x]_indg, not %hash_[x]_indg - changed interface of several helper subroutines for mapping in TileCoordRoutines.F90: use generic [indg] vectors so that subroutines can be called with %[x]_indg or %hash_[x]_indg
|
The program crashes. Need to figure out why |
Keep original i_indg and j_indg and use has_indg and hash_j_indg for the computation