At the moment there is no fallback options if a DVector is too big to fit in memory. A quick catch has been added to the generic_dunder method as memory can spike there, but nothing is included for handling DVectors which are actually too big.
The easiest way would be to make it so that DVectors can be saved to h5 files in chunks (either by a segment, or by some aggregate zoning). Then either there would be an option to select a chunk to read in manually, or the DVector itself could refer to a saved h5 file, rather than a DVector stored in memory. Any operations done on it could then cycle through chunks. It needs to be considered whether in the case of e.g. self * other, if one is set up this way if both need to be.
At the moment there is no fallback options if a DVector is too big to fit in memory. A quick catch has been added to the generic_dunder method as memory can spike there, but nothing is included for handling DVectors which are actually too big.
The easiest way would be to make it so that DVectors can be saved to h5 files in chunks (either by a segment, or by some aggregate zoning). Then either there would be an option to select a chunk to read in manually, or the DVector itself could refer to a saved h5 file, rather than a DVector stored in memory. Any operations done on it could then cycle through chunks. It needs to be considered whether in the case of e.g. self * other, if one is set up this way if both need to be.