Closed Kayne88 closed 1 year ago
Hi!
After tinkering with the code, I think that I found a partial solution to your issue. As suggested by the exception, SpearmanCorrCoef
expect its input to have either one or two dimensions. Due the internals of Darts, the shape of the tensors that are passed to this torchmetrics are both [32,24,1]
. At the moment, it's not possible to interact with these dimensions through darts but you could define a wrapper to take care of the dimension reduction:
class WrapperSpearman(SpearmanCorrCoef):
def update(self, preds, target):
super().update(preds.squeeze(), target.squeeze())
After solving this dimension issue, a new exception is raised saying that the second dimension of the target should be identical to the parameters num_ouputs
of the SpearmanCorrCoef. This problem can easily be solved by setting it to 24 when instantiating your metric.
Finally, the logger cannot accept a tensor of length 24 and suggest to call mean()
on the output. Its possible by wrapping around the compute
method:
def compute(self):
output = super().compute()
return output.mean()
As for the EarlyStopping
from PyTorch-Ignite, I think that you can get the PyTorch-Lightning trainer of the model by accessing the corresponding attribute model.trainer
(which will instantiated at the first call of fit
or predict
) and pass it to the EarlyStopping
object (as described in their example). I am not sure of how these modules will interact, if it does not work, I don't think that you could use PyTorch-Ignite trainer in darts models but I might be wrong...
That indeed works! Thanks for your investigation. Where is that 24 parameter coming from? Is it the training length, i.e. batch of the targets?
I was also wondering, when using historical_forecast, how is the "rolling" training split into train and val? I would ideally want to monitor the val_metric WrapperSpearman, whenever the model is retrained.
PS: I am using early stopping from pytorch lightning - from pytorch_lightning.callbacks.early_stopping import EarlyStopping
It's indeed the value of the training_length
argument of the FTF model.
The training split in historical_forecast is actually not "rolling" but "expanding", to cite the explanations in the method docstring: "
it repeatedly builds a training set from the beginning of series
. It trains the model on the training set, emits a forecast of length equal to forecast_horizon
, and then moves the end of the training set forward by stride
time steps".
TLDR; The training set grows incrementally as the historical_progress get closer to the last date.
For some model, this behavior can be disabled using the retrain
argument. If it's set to False, the model will be trained only on the first fragment of the input time-serie (up to the start
argument value) and the "expansion" will not occur.
I am not sure of where you could find the metric for each individual retrain: from my understanding of the source code, each model retrain will overwrite the metric obtained during the previous historical forecast since they share the same name/logger.
If you're interested in such feature, we can add it to the backlog and we would be very happy to have you contribute to the project by implementing it!
Yes, you are indeed right, "expanding" is the default.
My question regarding the retraining was more, if for each retrain there is a train-val split? Because in early stopping I would like to monitor the val metric, also for the historical_forecasts method.
Regard contribution: I am pretty new to pytorch and pytorch lightning. I would honestly not consider myself proficient enough.
Oh sorry, I misunderstood your question.
There is apparently no training-validation split during the retraining in the historical_forecasting
method but what you're looking for is the metric between the prediction of each "historical window" and the ground truth, right? Because from my small experiments, the validation loss/metric do not appear to be logged.
After verification, the reported values are indeed overwritten during model retraining and only the last one is available.
I'll add it to the backlog and start thinking about how to implement this feature.
Describe the bug Evaluation of spearmanr coef is failing due to shape mismatch. https://torchmetrics.readthedocs.io/en/latest/regression/spearman_corr_coef.html
Also, I am not sure, which key word to provide in EarlyStopping.monitor, when I want to monitor the provided torch metric in RNNModel.
To Reproduce
Expected behavior It is expected that the evaluation of the torch metric is working.
System (please complete the following information):
Additional context Full stack trace