Enable model to create output on different coordinates than source

[kacpnowak]

Is your feature request related to a problem? Please describe.

The current model's output functionality is coupled to the input data's coordinate system. It can only generate output data on the exact same geographical placements as the source data. This is a significant limitation for some downstream taks, (eg downscaling, limited area models) or when one needs to analyze the output on a standardized grid (like a regular lat-lon grid) or integrate it with other models and tools that use different meshing systems (e.g., HEALPix, different FESOM meshes).

Describe the solution you'd like

I propose implementing a feature that allows users to specify a target coordinate system for the model's inference, effectively decoupling the output grid from the source grid. This would involve modifying the data streams to create target coordinates that are different from the source coordinates.

Describe alternatives you've considered

I don't see any. I think it has to be done at some point

Additional context

No response

Organisation

AWI

[kacpnowak]

assign me

[github-actions]

Issue assigned to @kacpnowak.

[kacpnowak]

@grassesi @ankitpatnala

[jpolz]

Hi @kacpnowak
what would be the difference to specifying two streams, one with empty target and one with empty source? This can currently be done.

[kacpnowak]

Now every stream in the model has it's own decoder network. There must be some training data to get it to read out of the latent space. By injecting "fake coordinates" into existing streams we can use their decoders

[clessig]

This needs a design doc.

This has been requested by multiple people, e.g. also for SYNOPs. The question also has a lot of overlap with the climate roll-out that @ankitpatnala was working on, since there one also wants to have space/time coords, which do not have targets.

[kacpnowak]

Yes, definitely we need a design doc. @clessig are any other people that would be interested?

[ankitpatnala]

Yes, definitely we need a design doc. @clessig are any other people that would be interested?

I was drafting a design document for injecting time information into the climate rollout. This draft can be discarded, and instead, we can create a new version that fully addresses all of our requirements.

[grassesi]

Yes, definitely we need a design doc. @clessig are any other people that would be interested?

I would be up to do this 👍

[clessig]

Let us first collect the use cases that this should support. What I can think of:

• Decoding with given grid for specified range of dates
• Decoding data on new locations, e.g. SYNOP stations at new locations, including regular grids; new grid for existing grid decoder