Closed huard closed 7 years ago
Do you think this is something that needs fixing in the test suite?
Ideally yes. I just didn't take the time to investigate why the time field behaved differently and didn't want to leave it broken in the meantime.
My next objective is to implement custom icclim function in ocgis. My understanding is that icclim operates on daily data, but there are no checks at the moment for this. We'll face the same issue then so I'll be able to take a better look at this.
Ahhh, when I think about it what is happening is that time variables can have datetimes or floats for their main values. The preferred type can be accessed using methods: http://ocgis.readthedocs.io/en/latest/classes.html#ocgis.TemporalVariable.get_datetime and http://ocgis.readthedocs.io/en/latest/classes.html#ocgis.TemporalVariable.get_numtime. It can be a bit confusing but this makes the class more general.
My next objective is to implement custom icclim function in ocgis. My understanding is that icclim operates on daily data, but there are no checks at the moment for this. We'll face the same issue then so I'll be able to take a better look at this.
This sounds great. Let me know if you have any questions. You probably saw the ticket for this, but I'll link just in case #450. I don't know much about icclim
custom indices. It will be good to have @pagecp involved when necessary!
As far as daily data is considered, since most of the indices require daily data to calculate, it is why it is assumed that we have daily data for most of the indices. Some indices do not require daily data, and I do not see in the code anything that would prevent the use of non-daily data for basic calculations such as averaging.
When testing with the datasets that are automatically created by the ocgis test suite, the field['time'] values are datetime objects. When I tested with a real CMIP3 netCDF file, they are floats.