Scheduled Downtime
On Tuesday 24 October 2023 @ 5pm MT the forums will be in read only mode in preparation for the downtime. On Wednesday 25 October 2023 @ 5am MT, this website will be down for maintenance and expected to return online later in the morning.
Normal Operations
The forums are back online with normal operations. If you notice any issues or errors related to the forums, please reach out to help@ucar.edu

Interesting TAUX, TAUY in CESM2.1 B1850cmip6

AndrewLowry

Andrew Lowry
New Member
I have found some curious results in the TAUX and TAUY fields output to the h0 monthly cam history files for my picontrol simulation and I'm hoping someone can help me.

I have run a 31 year piControl simulation from the compset B1850cmip6 on resolution f09_g17, restarted with RUN_REFCASE=b.e21.B1850.f09_g17.CMIP6-piControl.001 and RUN_REFDATE=0501-01-01. The cesm model details and user_nl_cam and user_nl_clm files are attached.

To illustrate the issue I have plotted some output. The first two plots are the temporal average from cam of taux and tauy, with data masked for landfrac=0 (cam_taux_masked.png and cam_tauy_masked.png). These don't look right, so for my own sanity I plotted taux and tauy from pop (pop_taux.png and pop_tauy.png), which have values I would expect (e.g. westerly stress over 45-60S). To aide in comparison the cam plots are duplicated with the top plot using a colorbar bounded by max and min cam values and the bottom plot matching the colorbar from the pop plots. To check the model has sensible results, I plotted the lowest model level wind vectors (cam_uvwind_vector.png), which appear as one would expect.

As a further sanity check I plotted the pop and cam zonally averaged taux values (pop_taux_zonal.png and cam_taux_zonal.png). The cam_taux_zonal.png has an additional line where I have multiplied the result by -1, which is remarkably close to the pop result, once unit conversion is accounted for.

I'm hoping someone can tell me how to diagnose what might have gone wrong in my simulation? Is it simply that the definition of taux and tauy is positive(negative) = easterly (westerly), and thus multiplying the answer by -1 will produce the correct result? If this is true, can you point me to some documentation? Or is there something sinister going on, and if so what impact will this have had on other parts of the simulation?

As an aside to the above, this issue was detected after using the CESM Atmosphere Diagnostics Framework (github.com/NCAR/ADF), which produced the attached plot b.e21.B1850.f09_g17.CMIP6-piControl.001.SurfaceWindStress.png.
 

Attachments

  • cesm2.1.3version.txt
    4.9 KB · Views: 1
  • user_nl_cam.txt
    6.8 KB · Views: 3
  • user_nl_clm.txt
    7.7 KB · Views: 0
  • cam_taux_masked.png
    cam_taux_masked.png
    122.4 KB · Views: 8
  • cam_tauy_masked.png
    cam_tauy_masked.png
    124.3 KB · Views: 6
  • pop_taux.png
    pop_taux.png
    120.7 KB · Views: 3
  • pop_tauy.png
    pop_tauy.png
    116.4 KB · Views: 5
  • cam_uvwind_vector.png
    cam_uvwind_vector.png
    186.5 KB · Views: 5
  • b.e21.B1850.f09_g17.CMIP6-piControl.001.SurfaceWindStress.png
    b.e21.B1850.f09_g17.CMIP6-piControl.001.SurfaceWindStress.png
    125 KB · Views: 10

brianpm

Active Member
This may just be an issue with sign conventions, as you mentioned. I'm not sure. Can you compare with output from your REFCASE or other control run to see if TAUX and TAUY are consistent with your output?
 

AndrewLowry

Andrew Lowry
New Member
Hi, that is a great suggestion thanks. Yes it turns out the values in the refcase (b.e21.B1850.f09_g17.CMIP6-piControl.001) have the same property as my results. I also checked a different restart case from the input data directory and the values are similar as well. I assume therefore that it is probably a sign convention. It would be nice to know where some documentation on this is?
I also note that the Atmosphere Diagnostics Framework did not pick up the sign convention and plotted the vectors backwards.
 

brianpm

Active Member
I'm not sure why the sign convention is this way. It might just be based on the perspective of whether it is the momentum flux to the atmosphere or to the ocean (cf. Grachev 2003, JPO, "Wind stress over ocean waves"). The sign convention is briefly mentioned in the CAM5 tech note and in Lamarque et al. (2001; doi:10.5194/gmdd-4-2199-2011), but without any explanation.

I did take a quick look in the code, and it isn't immediately obvious where this is calculated. On the atmosphere side, CLUBB does read "cam_in%wsy" directly as the meridional momentum flux.

In terms of ADF, I'm not surprised that it doesn't flip the sign. I can raise this as an issue and get input about whether reversing the vectors should be specified as the default behavior (which we can do via a change in the adf_variable_defaults.yaml file to set the scaling factor to -1).
 
Top