[ENH] Implement `D2` layer and `BaseModel` class for `tslib` specific models.

[PranavBhatP]

Is your feature request related to a problem? Please describe.
Currently, there is a plan to implement a set of several models from tslib as a part of the v2 rework of pytorch-forecasting. These models provide the benefit of several added functionalities but require a unified layer to ensure quick and easy integration with the proposed D1 base dataset layer while retaining tslib specific functionality.

Describe the solution you'd like
The solution goes in line with the already proposed "D2" layer of v2. tslib models will have their own "D2" data module, which caters to different types of models and also handle the data preprocessing required for a completely functional model pipeline. This will be accompanied by a BaseTslibModel to provide an interface for implementing these models with their respective D2.

This proposed solution is in its early stages and is open to discussion and changes.

Additional context
Some designs of how tslib models might work with the v2 design are presented in the PR #1830.

[PranavBhatP]

I was also wondering if we could implement usage tags for models in PTF v2. The tags can correspond to the model architecture and something similar to the skbase _tags we have in sktime. FYI @fkiraly

[fkiraly]

I was also wondering if we could implement usage tags for models in PTF v2. The tags can correspond to the model architecture and something similar to the skbase _tags we have in sktime. FYI @fkiraly

Yes, I think that would be absolutely necessary - the prototype M layer in #1780 does introduce a full tag system, and translates the manually populated tables in pytorch-forecasting to the tags.

[PranavBhatP]

That's nice! I hadn't noticed it earlier in the PR.

[PranavBhatP]

I have some questions on the D2 design. After going through several tslib models, I noticed that a single data module might not be able to cater to these models.

So instead of having to make a separate data_module for each different architecture, I have come up with a design for a D2 (in the PR). But after going deeply through the tslib codebase, I noticed that the model are very diverse and making a data module which works with all, is a frustrating experience and quite difficult. I was wondering if we could stick to making the data module works for a certain set of models (transformer-based for example) would be a good way to go ahead? I have used a model_type parameter for this purpose. The amount of abstraction that is needed at the data module level is also something I am not able to judge properly.
(or)
Do we make several data modules for several types of models (all inheriting from a base data module)?

I will require some guidance in the design.

[agobbifbk]

Hello @PranavBhatP . I read all the tslib models and they almost have a forward function defined as:

def forward(self, x_enc, x_mark_enc, x_dec, x_mark_dec, mask=None):

as in the DSIPTS implementation (with different names).
Exception:

def forward(self, x_enc, x_mark_enc, x_dec, batch_y_mark, mask=None):

[here]We can investigating it when it comes the time, but we have it in DSIPTS so i think it will not be difficult to adapt it. Moreover here you can see that the forward step is agnostic respect to the model (there is only a flag respect to MS and adapt but I think it can be easily taken in consideration inside the model, not related to the D2 layer).
All the tslib can be seen as encoder-decoder architecture so I don't see the need for extra data modules for now.
For sure there will be a base class, but it mainly does the dirty stuff like tracking the loss, update the weights etc.
I hope this can help!
A

[PranavBhatP]

@agobbifbk, thanks for the feedback!

Moreover here you can see that the forward step is agnostic respect to the model (there is only a flag respect to MS and adapt but I think it can be easily taken in consideration inside the model, not related to the D2 layer).

I had looked at this previously, but the thought had not crossed my mind. Now it makes much more sense that a single D2 (data module) would be enough. I will trying adapting the tslib dataloader design, to the D2 proposed in the PR, and since all the models are framed as encoder-decoder style in the code (even though they are not necessarily enc-dec in their core architecture), we can restrict their individual logic to their separate classes, inheriting from a BaseTsLibModel.

This is what I infer from your comments, please correct me if I'm mistaken and suggestions for improvement are welcome.

[fkiraly]

Hm, if this is indeed the same format for everything, then we could try to reuse.

However, we should also check whether the type expectations are the same.

[PranavBhatP]

This issue can be closed as it has been addressed by the PR #1836.