Northerly ITCZ position in supposedly symmetrical aquaplanet slab ocean model

[aidenrobert]

Hello,

I'm running slab ocean aquaplanet (QSC6) simulations on CAM6 (from CESM v 2.1.0; no changes), with 1.9° resolution. I made a Q flux profile to match surface fluxes from a QOBS standard fixed SST run. My experiments need the control Q flux profile to be symmetrical, so I averaged the profile between hemispheres and mirrored it about the equator to ensure symmetry. The case is made using:

./create_newcase --case ../cases/aquaasym_CTL_v2 --walltime 24:00:00 --compset QSC6 --res f19_f19_mg17 --machine tetralith --project snic2022-1-1 --output-root /proj/bolinc/users/x_aidjo/cesm2.1.0-out/

I introduced seasonality by including orbital parameters in user_nl_cpl:

orb_eccen = 0.
orb_obliq = 23.5
orb_mvelp = 0.
orb_mode = "fixed_parameters"

And commented these two lines in the following block in seq_infodata_mod.F90 file and put it into SourceMods/src.drv/:

if ( infodata%aqua_planet ) then
infodata%aqua_planet_sst = 1
!infodata%perpetual = .true.
!infodata%perpetual_ymd = aqua_perpetual_ymd
endif

I have included a user_docn.streams.txt.som file with the path to the file, and made these xmlchanges:

$ ./xmlchange DOCN_SOM_FILENAME="aqua_baro_qflux_ctl.nc"
$ ./xmlchange STOP_OPTION=nyears,STOP_N=5,RESUBMIT=2
$ ./case.submit

The compiler is buildenv-intel/2018.u1-bare netCDF-HDF5/4.6.2-nsc1-parallel-private_hdf5-intel20018a-eb. Seasonality is working and after equilibrium is reached and checked against my prescribed Q flux profile, but I am getting a northerly ITCZ position. I have heard from a colleague that there can be multiple stable solutions and hysteresis in the position location's solution, but I also looked at the hemispheric differences in insolation, and there is a greater amount of annual average insolation in the SH than the NH, indicating there are some asymmetries – will need to solve this before proceeding.

Is it possible that the orbital eccentricity = 0 is not being passed to the model, and is there an extra line to comment/change in a source mod?

Thanks,
Aiden

 

[brianpm]

Hi Aiden,
It sounds like you've done things correctly, but the asymmetric SOLIN is a concern. I don't remember if I've seen this behavior before. How asymmetric is the insolation and how far north is the ITCZ? I have definitely seen asymmetric ITCZ structure in slab-ocean aquaplanets, but usually it has been a slightly enhanced rain band in one hemisphere compared to the other.

I think the orbital parameters should be correct. One thing you can do is to look in the log files and see if the correct values are being recorded. At least the atmosphere log file should provide that information.

A couple of other possible things:
1. How long is your test run? If it is relatively short and the asymmetry isn't too dramatic, then there could be some internal variability that could get damped in time. But the asymmetric SOLIN would still not make sense.
2. Does your Q-flux integrate to zero? If not, then it would introduce an energy imbalance. This could affect the solution, but again wouldn't explain the SOLIN.
3. If you run with orb_obliq=0, do you still have an asymmetry?

 

[aidenrobert]

Hey Brian,

Thanks very much for your response. The length of this simulation is not very long, I averaged over 5 years after 20 years spinup. The ITCZ is almost 10° north; if I look 5 years before, it is less northerly and has a slightly stronger southerly SH summer ITCZ position over a few years, so it is likely there is variability there. Will run it longer for better statistics.

Looking at the log files, I can confirm that it is using an eccentricity of 0. Realized that I forgot to include the changes I make to user_nl_cpl in the original post:

orb_eccen = 0.
orb_obliq = 23.5
orb_mvelp = 0.
orb_mode = "fixed_parameters"

Some replies to your answers:

1. The SOLIN asymmetry is still a mystery. First I suspected a lack of length of month weighting; I used CDO for the statistics and I think this does weight it, so I tried it in python without explicitly weighting and it is larger, so I believe CDO is actually doing the weighting (although the manual doesn't specify this for timmean, while it does for yearmean).The NH-SH asymmetry is -0.7 Wm-2.
2. The Q fluxes do not integrate to zero; I followed instructions to run a fixed SST simulation, get the surface energy fluxes from there, and then make a Q flux file to match them. I averaged each hemisphere's meridional profile and mirrored the profile to ensure symmetry. The Q fluxes integrate to about -12 Wm-2, which is balanced with TOA imbalance.
3. Yes, I made previous runs with orb_obliq=0 and the asymmetry is not there at all, it's basically perfectly symmetric (difference of 3E-12) – this led me to suspect something going wrong with the orbital forcing setting flag.

 

[brianpm]

Aiden --
Based on everything you've provided, I'm kind of stumped. I agree that it seems like the orbital parameters aren't being handled correctly, but since you are able to set orb_obliq to zero and get a symmetric solution, it's not just a setting being ignored. Your thought that the eccentricity might be the issue makes sense, but it's kind of strange that the SOLIN asymmetry you get is providing more energy to the SH yet your ITCZ is in the NH.

Does the ITCZ shift persist if your qflux is just zero? Can you make the ITCZ migrate to the SH by setting orb_obliq=-23.5 ?

I can try to reproduce your result on our system, but I'm not sure if I can do it this week. In the meantime, you could try to look for an eccentricity problem in cime/src/share/util/shr_orb_mod.F90. That code is pretty mature, so I'd guess the problem might come from some aquaplanet-specific code, but there's actually not much of that and you've already found the part that I would have thought to be relevant (i.e., in seq_infodata_mod.F90).

 

[aidenrobert]

Hi Brian,

Yeah, I'm sadly still stumped as well, after having looked at the code for a good amount of time last week. It truly doesn't make sense that the ITCZ is in the north if the eccentricity makes it so that the SH gets stronger insolation, though i tried to look into this a bit more (the eccentricity forcing on the ITCZ is not well documented either). I even got suspicious that CDO wasn't averaging across time correctly since it seemed not to be able to read the calendar type of the output, but after ensuring it was concatenating correctly I can confirm the time averaging was correct.

I am submitting a run with -23.5° obliquity to see if it does the opposite.

Thanks,
Aiden

 

[aidenrobert]

Hello again,

Just an update: changing obliquity to -23.5° results in a more symmetrical cloud and radiation field – the ITCZ and most fields are pretty much symmetric in the annual mean (attached a snapshot of CLDTOT below). There is still asymmetry in SOLIN (and I've double checked that month length weighting is being done properly). The negative obliquity reversed the NH minus SH asymmetry to -0.74 Wm-2 from +0.74 Wm-2. This tells me that eccentricity=0 is still getting overwritten somewhere in the code (despite the logs saying that it is receiving eccen=0). The exact orbital forcing combination of obliquity + eccentricity does matter for heat accumulation in the system (see Roach et al, 2023), which I'd like to remove to study the effects of hemispheric asymmetries in ocean heat fluxes with symmetric seasonality.

Changing the obliquity to -23.5° might be "good enough" for my purposes as a plumber's fix, but it likely doesn't remove seasonal asymmetries. A colleague and I will take a look at the code after the new year and see if we can find where it is getting overwritten.

 

[brianpm]

Thanks Aiden. I haven't had a chance to run your setup, so I'm thankful that you are still digging into it. Keep us updated if you find where eccentricity is sneaking in. I'd start with the slab ocean model; it is super simple, but maybe there's something we overlooked.

 

[aidenrobert]

Hi again,

Just an update – it seems like there was some kind of compilation error in our machine (Tetralith in Sweden's NSC). This problem occurred on the previous OS, and now that they have switched OS with new modules and different recommended compilers, my simulations compiled using these new ones respect orbital forcing inputs perfectly fine. Then I suppose it wouldn't have been reproduceable in other machines. Good news for CAM users anyhow, and thank you for the responses!

 

[brianpm]

Aiden - Thank you for the follow up! I'm glad the issue has been resolved. That's a very peculiar (IMO) behavior with the previous computing environment. At least our confusion about what was happening was justified.