Explore and discuss potential limitations adding `the_well` as a dep

[sgreenbury]

In #828 #840 the-well is added as a dep with benchmark extra. This enables emulators, training, config for benchmarking models from the-well to be incorporated directly here as subclasses.

This issue is to discuss potential limitations. Currently the following two are the main ones noted during implementing #840:

• For non-linux os, the dep triton needs to be built from source. This was possible when I tested on mac os with clang available.
• the neuralop dep is at 0.3 in the-well - it's possible features in more recent versions would be preferred to be included when impling new emulators.

[radka-j]

I would be in favour of adding The Well as dependancy for data handling but not for models (i.e., limitation 2 above). Is there anything that they add/handle in their model implementations that we would be missing if we use neuralop directly?

[sgreenbury]

Currently the main motivation for adding the [benchmark] extra is to bring in the training framework (inc. rollout model), logging, device handling etc. This is to train any of the models we would like to impl in conjunction with encoding options implemented as data formatters.

As you say an option could be to (re-)implement the models and the training etc. Another, at least while in this exploratory phase, could be to include the benchmark extra as a dep and then gradually replace parts as needed to reduce the dependence on the extra. In #863 this has been the case through overriding specific methods while still being able to subclass the dep Trainer as a base class.