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

negative salinity in CCSM3 POP run due to the imbalance between P and E

I am running CCSM3 POP (compset C), forced by surface fluxes from a previous fully coupled CCSM3 run.

The surface and upper ocean salinity evolves to zero or even negative, both at the marginal
seas and the seas far away from lands. I found that it is likely due to the imbalance between
Precipitation and Evaporation. Attached is a sample of the Prec and Evap in my CCSM3 POP
run (the terms of runoff and ice melting are 2-3 orders smaller, so they are not shown).

In my fully coupled CCSM3 runs, there is no this issue, and Prec is well balanced by Evap.
Through digging the code, I realize that the precipitation is from the atoms component
of the fully coupled CCSM3 run, and it is send to the ocean by the Coupler. But, the
evaporation is calculated by the Coupler itself. So, the real problem may be why the Coupler
gives a very imbalance Evap. If I manually adjust the global-mean Prec to be equal to Evap,
the surface salinity does not decrease or become negative.

I have tried several ways, including changing the values of ladjust_precip, lfw_as_salt_flx,
and/or lsend_precip_fact, in the pop_in. Neither of them works. I have also tried several
different forcings, including the conditions of present-day Earth and 630 million years ago.
All of the tests produce negative salinity.

Does CESM POP run have the same issue?

It will be very appreciated if anyone could give me some suggestions.
Thank you very much!
 

njn01

Member
Jun Yang,
I will not be able to address your question directly, but I wanted to make a couple of comments that may be helpful to you.
First, the CCSM3 is no longer supported. See https://www2.cesm.ucar.edu/models/legacy for details.Second, the "C" compset (also referred to as the "ocean-only" compset) was never intended for scientific studies. Note that in the C compset, the forcing loops over a one-year interval regardless of how long you run your model.Instead of using the CCSM3 "C" compset for your work, I recommend that you use the most recent CESM release and select the "CIAF" compset (C, interannual forcing compset). You can read about this compset in the CESM POP2 FAQ, located athttp://www.cesm.ucar.edu/models/cesm1.2/pop2/doc/faq/#IAF-- N
 

njn01

Member
Jun Yang,
I will not be able to address your question directly, but I wanted to make a couple of comments that may be helpful to you.
First, the CCSM3 is no longer supported. See https://www2.cesm.ucar.edu/models/legacy for details.Second, the "C" compset (also referred to as the "ocean-only" compset) was never intended for scientific studies. Note that in the C compset, the forcing loops over a one-year interval regardless of how long you run your model.Instead of using the CCSM3 "C" compset for your work, I recommend that you use the most recent CESM release and select the "CIAF" compset (C, interannual forcing compset). You can read about this compset in the CESM POP2 FAQ, located athttp://www.cesm.ucar.edu/models/cesm1.2/pop2/doc/faq/#IAF-- N
 

njn01

Member
Jun Yang,
I will not be able to address your question directly, but I wanted to make a couple of comments that may be helpful to you.
First, the CCSM3 is no longer supported. See https://www2.cesm.ucar.edu/models/legacy for details.Second, the "C" compset (also referred to as the "ocean-only" compset) was never intended for scientific studies. Note that in the C compset, the forcing loops over a one-year interval regardless of how long you run your model.Instead of using the CCSM3 "C" compset for your work, I recommend that you use the most recent CESM release and select the "CIAF" compset (C, interannual forcing compset). You can read about this compset in the CESM POP2 FAQ, located athttp://www.cesm.ucar.edu/models/cesm1.2/pop2/doc/faq/#IAF-- N
 
Hi njn01, Thank you for your reply. Because I have done some paleoclimate simulations with CCSM3and also now I only know how to modify the land-sea distribution in CCSM3, I keep workingwith CCSM3. In the future, I plan to use CESM1.Fortunately, I found the reason and the solution for the negative salinity issue.  REASON: In compset C of CCSM3, the daily mean surface downward solar radiation is send to the Coupler from the atmos component, meanwhile, the Coupler computes the ocean surface albedo. With this two variables, the Coupler computes the net surface solar radiation and send it to the ocean component. There are two chooses for calculating the ocean surface albedo: (1) one is daily mean without considering the zenith angle dependence, and (2) the other one is instantaneous with the zenith angle dependence. By default, the Coupler uses the second one, i.e., dayily mean downward solar radiation * instantaneouos surface albedo. On the dark side, there is no solar absorption, so the net solar radiation send to the ocean components is much smaller than that expected. As a result, the Evap. is much smaller than Prec.For details, please see the subroutin flux_albo in cpl/cpl6/flux_mod.F90 SOLUTION: turn on the namelist variable "flux_albfb" in the cpl namelist.i.e., flx_albav     = .true. (by default, it is .false.)With this set, the Coupler uses the daily mean ocean surface albedo.  
 
Hi njn01, Thank you for your reply. Because I have done some paleoclimate simulations with CCSM3and also now I only know how to modify the land-sea distribution in CCSM3, I keep workingwith CCSM3. In the future, I plan to use CESM1.Fortunately, I found the reason and the solution for the negative salinity issue.  REASON: In compset C of CCSM3, the daily mean surface downward solar radiation is send to the Coupler from the atmos component, meanwhile, the Coupler computes the ocean surface albedo. With this two variables, the Coupler computes the net surface solar radiation and send it to the ocean component. There are two chooses for calculating the ocean surface albedo: (1) one is daily mean without considering the zenith angle dependence, and (2) the other one is instantaneous with the zenith angle dependence. By default, the Coupler uses the second one, i.e., dayily mean downward solar radiation * instantaneouos surface albedo. On the dark side, there is no solar absorption, so the net solar radiation send to the ocean components is much smaller than that expected. As a result, the Evap. is much smaller than Prec.For details, please see the subroutin flux_albo in cpl/cpl6/flux_mod.F90 SOLUTION: turn on the namelist variable "flux_albfb" in the cpl namelist.i.e., flx_albav     = .true. (by default, it is .false.)With this set, the Coupler uses the daily mean ocean surface albedo.  
 
Hi njn01, Thank you for your reply. Because I have done some paleoclimate simulations with CCSM3and also now I only know how to modify the land-sea distribution in CCSM3, I keep workingwith CCSM3. In the future, I plan to use CESM1.Fortunately, I found the reason and the solution for the negative salinity issue.  REASON: In compset C of CCSM3, the daily mean surface downward solar radiation is send to the Coupler from the atmos component, meanwhile, the Coupler computes the ocean surface albedo. With this two variables, the Coupler computes the net surface solar radiation and send it to the ocean component. There are two chooses for calculating the ocean surface albedo: (1) one is daily mean without considering the zenith angle dependence, and (2) the other one is instantaneous with the zenith angle dependence. By default, the Coupler uses the second one, i.e., dayily mean downward solar radiation * instantaneouos surface albedo. On the dark side, there is no solar absorption, so the net solar radiation send to the ocean components is much smaller than that expected. As a result, the Evap. is much smaller than Prec.For details, please see the subroutin flux_albo in cpl/cpl6/flux_mod.F90 SOLUTION: turn on the namelist variable "flux_albfb" in the cpl namelist.i.e., flx_albav     = .true. (by default, it is .false.)With this set, the Coupler uses the daily mean ocean surface albedo.  
 

njn01

Member
Jun Yang,
Thank you for your detailed follow-up and for posting the cause and solution of the problem you encountered.  Given the circumstances (previous work in CCSM3, difficulty in modifying land-sea boundaries),  it makes sense that you are still using CCSM3.  I'm very glad that you were able to figure out and correct the problem, and you definitely get extra bonus points for sharing this information with the community :-)Note that when you use CESM1 to set up a C-compset case, the ocean and coupler namelist settings are now automatically set up correctly for you. This was not the case in CCSM3, which you unfortunately discovered the hard way.After re-reading your original message, I realized that I overlooked your statement that you were using customized fluxes from a previous CCSM3 run. So my response about the annual forcing did not apply to your particular situation, although I think it doesn't hurt to reiterate in this post that out-of-the-box C compsets are not intended for scientific experiments. (In CESM1, you can use CIAF instead; see the POP2 FAQ for more details)
 

njn01

Member
Jun Yang,
Thank you for your detailed follow-up and for posting the cause and solution of the problem you encountered.  Given the circumstances (previous work in CCSM3, difficulty in modifying land-sea boundaries),  it makes sense that you are still using CCSM3.  I'm very glad that you were able to figure out and correct the problem, and you definitely get extra bonus points for sharing this information with the community :-)Note that when you use CESM1 to set up a C-compset case, the ocean and coupler namelist settings are now automatically set up correctly for you. This was not the case in CCSM3, which you unfortunately discovered the hard way.After re-reading your original message, I realized that I overlooked your statement that you were using customized fluxes from a previous CCSM3 run. So my response about the annual forcing did not apply to your particular situation, although I think it doesn't hurt to reiterate in this post that out-of-the-box C compsets are not intended for scientific experiments. (In CESM1, you can use CIAF instead; see the POP2 FAQ for more details)
 

njn01

Member
Jun Yang,
Thank you for your detailed follow-up and for posting the cause and solution of the problem you encountered.  Given the circumstances (previous work in CCSM3, difficulty in modifying land-sea boundaries),  it makes sense that you are still using CCSM3.  I'm very glad that you were able to figure out and correct the problem, and you definitely get extra bonus points for sharing this information with the community :-)Note that when you use CESM1 to set up a C-compset case, the ocean and coupler namelist settings are now automatically set up correctly for you. This was not the case in CCSM3, which you unfortunately discovered the hard way.After re-reading your original message, I realized that I overlooked your statement that you were using customized fluxes from a previous CCSM3 run. So my response about the annual forcing did not apply to your particular situation, although I think it doesn't hurt to reiterate in this post that out-of-the-box C compsets are not intended for scientific experiments. (In CESM1, you can use CIAF instead; see the POP2 FAQ for more details)
 
Top