User provided time_dict
klapo opened this issue · comments
Is your feature request related to a problem? Please describe.
The current DMD base class builds its own time series in _set_initial_time_dictionary in dmdbase.py based purely on the length of the time dimension using dt=1. This lack of transparency in the time dimension can result in ambiguities when interpreting and comparing methods.
Example 1: The frequencies from dmdbase.frequency are incorrectly scaled using dt=1. This scaling issue is not transparent, potentially leading to incorrect interpretations.
Example 2: When trying to evaluate a forecast from a dmd fit, the time series used for forecasting has to be scaled to match dmd time series. e.g., the input data are from t1 to t2 and the forecast period is from t2 until t3 with a dt=0.01. To forecast the data from the exact DMD one must do something like the following :
dmd.dmd_time['t0'] *= t2 * dt
dmd.dmd_time['tend'] *= t3 * dt
Describe the solution you'd like
My preferred solution would be for the user to have the option to pass in the time_dict parameter.
Describe alternatives you've considered
My alternative is currently the above, where I scale everything outside of DMD manually.
Additional context
The definition of time series becomes particularly ambiguous since the new BOPDMD actually allows a user to provide the time data directly.
Potentially related to this issue would be adding a forecast() method to the dmdbase class resembling the bopdmd.forecast() method, in which a user can provide a time series for forecasting.
The best for me would be to move the whole temporal information into an optional parameters to reconstructed_data (which should then become a method).
The idea in that case would be to have something like the below?
dmd.fit(x)
reconstructed_data = dmd.reconstruct(t_recon)
forecasted_data = dmd.reconstruct(t_forecast)
I was thinking something like this:
dmd.fit(x)
rec_data = dmd.reconstruct(t0=..., tend=..., dt=...)I don't see the need of an additional dict, and this way we can leverage default values (which would be t0=0, tend=-1, dt=1). Also one method for both reconstruction and prediction I think is enough.
adding parameters to reconstructed_data breaks retro compatibility: we can plan for the next major release.
But I've not really understood the solution: now 2 dictionaries are needed, one with the information regarding the collected snapshots, and one with the information for the reconstruction, you want to pass both @fAndreuzzi ?
Actually I was thinking about replacing only the dictionary related with the reconstruction provided by DMD @ndem0
Thinking about this some more and I think a time dictionary should be optionally passed to both the fitting and the reconstruction. Several parameters (e.g., growth rate) depend on the actual dt. Assuming dt=1 (as is the current case) can give misleading results.