Public issueshttps://gitlab.ethz.ch/groups/tec/public/-/issues2019-11-15T15:36:08Zhttps://gitlab.ethz.ch/tec/public/employees/matthias-meyer/stuett/-/issues/2Default __call__ of Nodes2019-11-15T15:36:08ZmatthmeyDefault __call__ of NodesA new change I will introduce is that the Nodes __call__ function is not a dask.delayed function by default.
This has already been partially implemented in the develop branch, but still needs to be finished.
The intuition is that the ...A new change I will introduce is that the Nodes __call__ function is not a dask.delayed function by default.
This has already been partially implemented in the develop branch, but still needs to be finished.
The intuition is that the nodes should be usable without having to work with a dask graph.
There will be an option (global and per node) which enables dask.delayed wrapping of the __call__ function.
@tkuonen will need to consider this when implementing the visualization.https://gitlab.ethz.ch/tec/public/employees/matthias-meyer/stuett/-/issues/1Timezone issues with xarray dataarray2019-11-14T19:08:50ZmatthmeyTimezone issues with xarray dataarrayLike described in this issues [1](https://github.com/pydata/xarray/issues/3291) [2](https://github.com/pydata/xarray/issues/3320), if we use timezone aware inputs as datetime coordinates in xarray it will be converted to an object instea...Like described in this issues [1](https://github.com/pydata/xarray/issues/3291) [2](https://github.com/pydata/xarray/issues/3320), if we use timezone aware inputs as datetime coordinates in xarray it will be converted to an object instead of datetime.
If we convert it with pd.to_datetime() when we want to use it is not an issue but if we want to use slicing this is an issue.