implementing a "grow_coordinate" function to grow / reallocate larger arrays copying the previous chunk along a coordinate

this sounds a lot like pad with mode="constant"?

is it possible that xarray makes no assumptions of this kind

xarray uses pandas indexes for alignment and indexing (if you have a recent version of xarray you should see the "Indexes" section in the HTML repr), so yes, it will always make sure to use a search that is more efficient than the linear search, as long as the data is sorted. This was also the reason why you had to use swap_dims / set_index to create an index along the coordinate you wanted to reindex.

Does this more or less represent your Dataset?

```python import numpy as np import xarray as xr import datetime

create two timeseries', second is for reindex

itime = np.arange(0, 3208464).astype("<M8[s]") itime2 = np.arange(0, 4000000).astype("<M8[s]")

create two dataset with the time only

ds1 = xr.Dataset({"time": itime}) ds2 = xr.Dataset({"time": itime2})

add random data to ds1

ds1 = ds1.expand_dims("station") ds1 = ds1.assign({"test": (["station", "time"], np.random.rand(106, 3208464))}) ```

Now we reindex with the longer timeseries, it only takes a couple of seconds on my machine:

python %%time ds3 = ds1.reindex(time=ds2.time) CPU times: user 3.16 s, sys: 649 ms, total: 3.81 s Wall time: 3.81 s

Data is unchanged after reindex:

python xr.testing.assert_equal(ds1.test, ds3.test.isel(time=slice(0, 3208464)))

@jerabaul29 Concerning possible slowness of reindex, I think it uses some sorting inside. But isn't a timeseries sorted anyway? Nevertheless you have a point here, that reindex might not be the right tool for this use-case. It would be nice of we could create your dataset in memory with some random data and check the different proposed solutions for their performance.

@jerabaul29 Does your Dataset with the 3 Million time points fit into your machine's memory? Are the arrays dask-backed? It is unfortunately not seen in the screenshots. Calculating from the sizes this is 106 x 3_208_464 single measurements -> 340_097_184. Going from float (8 byte) this will lead to 2_720_777_472, roughly 2.7GB which should fit in most setups. I'm not really sure but good chance that reindex is creating a completely new Dataset, which means the computer has to hold the origin as well as the new Dataset (which is roughly 3.2GB). This adds up to almost 6GB RAM. Depending on your machine and other tasks this might drive into RAM issues. But xarray devs will know better.

@keewis suggestion of creating and concatenating a new array with predefined values which is file-backed could resolve the issues you are currently facing.

I'm a bit surprised. Could you post a repr of timestamps_extended_basis? That might help figuring out what exactly happened.

If everything fails, you might also create a new xarray object with just the new values, and then use xr.concat to combine both?

I think this is because you don't have an index along the dimension. Try any of python previous_observations.set_coords(["timestamps"]).swap_dims({"time": "timestamps"}).reindex(...) previous_observations.set_index({"time": "timestamps"}).reindex(...) (the only difference is the name of the dimension / coordinate you end up with)

You could take the exact time you have and just add the addition times. You even might create those additional ones by giving a timeinterval and the number . I'd need to look up , but I'm currently only on phone.

Would xarray.Dataset.reindex do what you want?

You would need to extend you time array/coordinate appropriately and feed it to reindex. Maybe you also need to provide fillvalue keywords to get your need portions filled with the correct fillvalue.