Bnb/1d nc loading #247
Bnb/1d nc loading #247
Conversation
…pass chunk shape. For some grid sizes and forward pass chunk shapes not forcing this minimum shape can result in a chunk that is too small for the generator. Fixed slice test, which was not checking all slices.
…tor padding layer requirements.
…cing values (hr_cropped_slices, for example) depend a lot on the pad width implementations so these should be grouped.
bnb32
force-pushed
the
bnb/1d_nc_loading
branch
from
587c375 to
11acb62
Compare
| lr_slice_stop, | ||
| self.spatial_pad, | ||
| ) | ||
| warn( |
There was a problem hiding this comment.
I feel like this should almost be an exception and force you to adjust your fwp shape... It could result in some pretty garbage data. Does this increase the chunk size for the last chunk and crop more of the output? And leave the neighboring chunk alone? Actually that makes sense. Does this check vertical chunk dims too?
There was a problem hiding this comment.
Yeah this pads only the "final" chunk and then crops the output more. This is done for each spatial dimension so it ends up padding the right-most and bottom-most boundary. True edge case here since it almost never happens when you have non-zero spatial padding and then only happens if spatial padding is 1 and the last unpadded chunk size is also 1.
There was a problem hiding this comment.
Gotcha that makes sense. good solution too!
Some adjustments to loaders so they work nicer with flattened nc data. Also fix for slicer edge case where
modulo(grid_shape, fwp_chunk_shape)is too small for generator padding layer requirements.