Redo our "first results" with relative winds (instead of absolute)

[paigem]

Rerun the "first results" (see #32) for CM2.6 using relative winds. Currently all results shown use absolute winds.

This was based on discussions on Friday, Sep. 30th (notes here).

[jbusecke]

I think getting this issue sorted should be our first priority right now, because it would enable me to redo the results from #32 and enable others to work from that data. The key issue to resolve here is if we are ok with treating the vector components as scalars (which would mean we separately interpolate them, take the difference, and then calculate the relative wind at high resolution).

[paigem]

I think that treating the winds as scalars is a fine place to start. My minimal intuition comes from using gcm-filters, where I smoothed velocities based on scalars and vectors and the results were similar (though I don't have any plots to show this...).

So if I'm understanding your suggestion @jbusecke, our method would be the following:

• Interpolate oceanic u and v to the atmosphere grid
• Take the difference between atmospheric u and ocean u (and same for v)
• Input this difference in u and v to aerobulk-python

Is this correct @jbusecke?

[jbusecke]

Your proposed method would give us velocities on the atmospheric grid center, which we cannot use with other outputs on the oceanic cell center. More importantly in this step:

Interpolate oceanic u and v to the atmosphere grid

we would downsample the oceanic velocities (to the lower resolution atmospheric grid), which I think we want to avoid.

Instead I believe these are the steps we should take:

• Interpolate oceanic u and v to the ocean cell center (from their positions at the cell edge)
• Interpolate atmospheric velocities to the ocean cell center (from their position at the atmospheric cell center).
• Take the difference between each of the components on the ocean cell center position
• Run the computation with the resulting relative wind components.

Does this make sense?

[paigem]

I agree @jbusecke with your method! It makes sense to "upsample" the atmospheric data rather than downsampling the ocean.

I suppose we can add another step at the end where we downsample the relative winds back to the atmospheric grid to input into aerobulk-python.

[jbusecke]

I suppose we can add another step at the end where we downsample the relative winds back to the atmospheric grid to input into aerobulk-python.

The actual calculation is happening on the ocean tracer grid anyways, so I think this would just introduce more complexity?

[paigem]

Yep, my bad! I forgot about the regridding step in our workflow when I wrote that yesterday... 😅

[jbusecke]

Hey @ocean-transport/collab_team, I have implemented the relative wind as input for the flux calcuation according to our last meeting.

FYI here are some sample (single timestep) of the difference between using absolute and relative wind:

Latent Heat Flux

First the two fields as computed by ab:

Left: Absolute wind, Right: Relative wind

And the difference (colorbars correspond to 5% of the figure above)

Sensible Heat Flux

First the two fields as computed by ab:

Left: Absolute wind, Right: Relative wind

And the difference (colorbars correspond to 5% of the figure above)

Thats quite a difference for both fields (evaporation looks similar to the latent heat flux). It remains to be seen how that translates to the small/large scale decomposition.

Just thought Id document this here.

[rabernat]

Great work Julius!