Minor cleanup in datatypes

[brownbaerchen]

While preparing for the NeuralPinT kickoff meeting, I thought we can trim the datatypes a lot by making the communicator a class attribute and do a nice Tensor datatype in this way.
Keep in mind that class attributes are shared between all instances of a class, but only across one task. That means we can assign different communicators to the class on different MPI processes and get essentially the same behaviour as before. I added a test to make sure this is actually the case.
Indeed, this allows to remove a lot of stuff from the datatypes.
Sadly, though, I noticed the problem with Tensor is the frequent cloning of tensors, which I was not able to remove right now. So I didn't solve the problem I set out to solve, but I still consider this better than before.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.13%. Comparing base (18989d3) to head (4039cbb).
Report is 16 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #438      +/-   ##
==========================================
+ Coverage   77.38%   78.13%   +0.74%     
==========================================
  Files         327      329       +2     
  Lines       26085    26146      +61     
==========================================
+ Hits        20187    20430     +243     
+ Misses       5898     5716     -182     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tlunet]

Love the idea of what you are doing ... in practice, data-types can be made way much simpler indeed, I started to do something similar some time ago, a very first mix of the MultiComponent Datatype, and the inclusion of the communicator as class attribute : https://github.com/Parallel-in-Time/pySDC/tree/master/pySDC/playgrounds/datatypes

Did you look at it already ? There may be some stuff that can be useful in there (in particular, no need to override the new or __array__finalize methods of ndarray ...)

[brownbaerchen]

Ah, nice! I forgot that you were doing this. Indeed, you can remove __array_finalize__ by use of class attributes. However, it seems that you got rid of the init thing in the problem classes. This is why I still have the __new__. To have a shared interface for the datatypes that gives you what you want when you put in (shape, communicator, dtype).
I was thinking that we can maybe store a function signature to replace object instantiation also in a class attribute. Something like

class mesh(np.ndarray):
    init = {'shape': None, 'dtype':np.float64}

@classmethod
def set_init(cls, shape, dtype):
    cls.init = {'shape': shape, 'dtype': dtype}

@classmethod
def init(cls):
    return np.ndarray(**cls.init).view(cls)

And then we can replace problem.u_init() with problem.dtype_u.init().
Didn't think carefully about this, not sure if this is the best way to do it. But I do think we want some common way of doing this across datatypes. Then again, I am not sure about this. Annoyingly, for instance, the torch.Tensor class does not allow a signature of shape and dtype in __new__, which may complicate things.

[pancetta]

Any progress here?

[brownbaerchen]

Personally, I vote to merge this and wait for a big cleanup. Nobody has time to change the entire interface of the datatypes now. This would be a small increment towards what @tlunet wants.

[pancetta]

Why not _comm here?

[brownbaerchen]

I removed the getter function. I honestly don't see the point. But I can add it back in if you want.

[pancetta]

I "get" it. Let's keep it explicit, then.

[tlunet]

We can still have private "explicit" attributes denoted by the leading _, but no getter and setter (which are indeed superfluous)