Refactor steps in blending code

[sidekock]

Issue #395 should be done for the blending code aswel.

[sidekock]

I have started with the rough outlines of the code but will work on it later this week.

[sidekock]

@mats-knmi I have a question regarding the ndim=4 check you did to determine if the forecast provided has been decomposed already or not. I see a lot of potential for problems here. Let me try and list my assumptions and downsides below, I would love to hear your thoughts on possible solutions:

• I think the 4 dims is due to the assumption (member, timesteps, x, y).
• But what in the case someone has a single member they want to blend, then (timesteps, cascade levels, x, y) is also 4D
• Do you think an extra flag in the config data class would be the way to go? If so, what do we assume to be the default value? (I would say, decomposed as a basis as this is not introducing breaking changes)
  Would love to hear your feedback on this.

[mats-knmi]

I didn't create this check, it was already in the original code, I just moved it around. There is a line in the docstring telling users to add a dimension in the case you describe.

I do agree that this is less then ideal. In my opinion the ideal solution would involve xarray, because in the case of an xarray dataset all dimensions would be named and thus you wouldn't have to assume anything based on the number of dimensions. You could do something like if "member" in dataset:.

The xarray conversion I have been working on has been on hold for a bit, since I have been busy with other things, but the nowcasting code had already been entirely converted to xarray and I have merged your refactored code in there.