Storm day restart date #194
Conversation
…mezone, made it more robust
| @@ -134,28 +134,32 @@ def initialize(self, topo, data, date_time=None): | |||
| self._logger.debug('Reading {} from {}'.format( | |||
| 'storm_days', self.config['storm_days_restart'])) | |||
| f = nc.Dataset(self.config['storm_days_restart'], 'r') | |||
| f.set_always_mask(False) | |||
There was a problem hiding this comment.
Never used this. What does it do?
There was a problem hiding this comment.
netCDF4 in their infinite wisdom decided to return a numpy masked array all the time, even if there is no fill values. So this returns a normal numpy array which is faster and easier to deal with. The masked arrays are the opposite of what we think them to be where the mask is the values we don't want.
There was a problem hiding this comment.
xarray doesn't do this, just saying.... 😉
There was a problem hiding this comment.
Ha ... still not sold on Xarray being the all mighty ;-)
I might be misunderstanding this with the description, but is the mask by netCDF saying True when a value is incorrect and 'False` where it is correct?
There was a problem hiding this comment.
Haha, I know it's not, it's just convenient sometimes.
"When an element of the mask is False, the corresponding element of the associated array is valid and is said to be unmasked. When an element of the mask is True, the corresponding element of the associated array is said to be masked (invalid)."
This has caught us in the past because our convention is that a mask is True where the data is valid.
There was a problem hiding this comment.
I can see the argument for that behaviour of netCDF. For instance rasterio follows the same principle: https://rasterio.readthedocs.io/en/latest/topics/masks.html
There was a problem hiding this comment.
It's probably specific to our (IPW and hydrology) representation of what mask is, whether it's inside or outside of a basin.
|
Any quick test that can be added? |
Probably but we don't have a storm day netcdf that is in the test data. Right now, the test is in AWSM during the restarting tests, which was how this was discovered. |
The timezone wasn't being set when using the storm days restart file. Cleaned this up to ensure that we're comparing python datetime objects instead of cftime and pd.Timestep.