Comments (11)
Bill Sacks < [email protected] > - 2013-10-16 10:06:16 -0600
Oops, didn't finish that; to finish:
The two related problems are:
(1) max_dayl is computed using an orbital parameter that is hard-coded for present-day
(2) max_dayl is set in initialization, then doesn't change... this isn't itself a problem currently, but would be a problem if we set it based on the actual, current orbital parameters
So I propose the following solution:
(1) Create a new function in DaylengthMod that computes the max daylength for a given grid cell. This would look like:
elemental real(r8) function max_daylength(lat, obliquity)
max_decl = obliquity
if (lat < 0) max_decl = -max_decl
max_daylength = daylength(lat, max_decl)
end function
(2) Do NOT set max_dayl in iniTimeConst. Instead, call the above function wherever it is needed - currently, this is just in one place, in CanopyFluxesMod.F90. So here we could have a local variable, max_dayl, and calculate it as:
max_dayl(begg:endg) = max_daylength(lat, obliquity)
(3) We then have to get the obliquity from the coupler, which I believe is already done in this call in lnd_comp_mct:
call shr_orb_decl( calday , eccen, mvelpp, lambm0, obliqr, declin , eccf )
and then pass obliquity as an argument to the driver, which will then pass it along to CanopyFluxes.
I would like confirmation from Nan and Erik on these points:
(a) Nan (or Erik): Is obliquity the correct parameter to use here? What we want is the maximum solar declination angle; in iniTime const this is set as:
! +/- 23.4667 degrees = +/- 0.409571 radians, use negative value for S. Hem
So, is that the obliquity?
(b) Mostly for Erik: Does this seem like a reasonable solution? And do you agree with the overall design I am proposing? In particular, does it make sense to get obliquity in lnd_comp_mct and pass it down the call chain? The alternative would be to call shr_orb_decl from within the max_daylength function, but from our brief shuttle conversation, it sounded like there is some design reason to get these sort of parameters at the top level and then pass them down?
from ctsm.
Bill Sacks < [email protected] > - 2013-10-16 10:11:01 -0600
This change will almost certainly change answers slightly, even for present-day runs (because I imagine that the hard-coded max declination angle in iniTimeConst doesn't agree completely with CESM's obliquity).
So for testing purposes, this should be done in two steps:
(1) Simply change the hard-coded max declination angle in iniTimeConst to agree with CESM's obliquity. This will change answers. (If this differs for different time periods, e.g. 1850 vs 2000, I may want to introduce a kludge so that the hard-coded value keys off of the time period of the run (or maybe introduce a call in iniTimeConst to shr_orb_decl) - so that this hard-coded value always agrees with CESM's obliquity at initialization.
(2) Do my proposed refactoring. For runs in which the orbital parameters are fixed throughout the run, this should be bfb with #1.
from ctsm.
Bill Sacks < [email protected] > - 2013-10-16 10:13:16 -0600
Oops, when I said "or maybe introduce a call in iniTimeConst to shr_orb_decl" I meant shr_orb_params
from ctsm.
Bill Sacks < [email protected] > - 2013-12-17 11:18:05 -0700
Un-assigning myself from this... I was only assigned to this because it came up in the course of my work a few months ago, but it's not currently relevant for me.
from ctsm.
Bill Sacks < [email protected] > - 2015-05-08 09:44:02 -0600
Looking back at this bug report, I noticed a typo in the initial bug report:
In talking with Nan, this could be a problem for present-day runs.
Should read:
In talking with Nan, this could be a problem for PALEO runs.
from ctsm.
Erik Kluzek < [email protected] > - 2017-11-02 15:01:17 -0600
The simplest change to accomplish this is to just do...
Index: main/clm_initializeMod.F90
===================================================================
--- main/clm_initializeMod.F90 (revision 87306)
+++ main/clm_initializeMod.F90 (working copy)
@@ -385,11 +385,10 @@
call InitDaylength(bounds_proc, declin=declin, declinm1=declinm1)
! Initialize maximum daylength, based on latitude and maximum declination
- ! maximum declination hardwired for present-day orbital parameters,
- ! +/- 23.4667 degrees = +/- 0.409571 radians, use negative value for S. Hem
+ ! given by the obliquity use negative value for S. Hem
do g = bounds_proc%begg,bounds_proc%endg
- max_decl = 0.409571
+ max_decl = obliqr
if (grc%lat(g) < 0._r8) max_decl = -max_decl
grc%max_dayl(g) = daylength(grc%lat(g), max_decl)
end do
This looks correct to me, since in shr_orb_calc
declin = asin(sin(obliqr)*sin(lamb))
lamb represents the earth going around the sun, so we just want the point where sin(lamb)==1. So you have
declin = asin(sin(obliqr)*1) = obliqr
So the above change is the quickest solution to the right answer. Other refactoring could be done later.
from ctsm.
Bill Sacks < [email protected] > - 2017-11-02 16:41:17 -0600
Erik: At a glance, your solution looks like a simple and reasonable solution for the first problem:
(1) max_dayl is computed using an orbital parameter that is hard-coded for present-day
but doesn't address
(2) max_dayl is set in initialization, then doesn't change... this isn't itself a problem currently, but would be a problem if we set it based on the actual, current orbital parameters
It probably still makes sense to bring your solution to the trunk, since that solves the first-order problem. But then we should open a separate issue to eventually solve (2), since my understanding is that that's needed if you have time-evolving orbital parameters.
from ctsm.
Erik Kluzek < [email protected] > - 2017-11-02 17:32:31 -0600
A few years ago there was only the option to set orbital parameters at initialization. It looks like there is now the hardware in place to actually change it each year. But, this isn't normally exercised, and I couldn't find any tests that actually turn it on. Compsets don't seem to trigger it either. Since it's untested I wonder if it actually works? But, in any case, the simple change is an improvement, since it'll be aligned for the first year, and just slowly be off which each passing year. The simple change will be right for everything we test, and just off for a feature that isn't tested.
from ctsm.
Bill Sacks < [email protected] > - 2017-11-02 17:53:41 -0600
Okay, thanks for those details.
from ctsm.
Erik Kluzek < [email protected] > - 2017-11-08 16:06:15 -0700
clm4_5_17_r263 does a partial fix to this by correcting it at initialization. variable_years will be wrong though.
from ctsm.
@ekluzek I'm closing this issue, and opening #260 to document the remaining issue.
from ctsm.
Related Issues (20)
- Support needed for ne16np4 in addition to ne16np4.pg3? HOT 6
- ne0ARCTICne30x4 grid transient failure
- Do we need transient support for ne30np4 in addition to ne30np4.pg3? -- answer NO HOT 4
- Update fire scheme HOT 13
- test issue HOT 1
- Failing PEM (PE layout change test) in ctsm5.2.005 HOT 4
- BLT1850.ne30_t232 case failing with use_init_interp not properly set to true
- Make sure our baseline directories are readable outside the group HOT 4
- error generating landuse_timeseries using mksurf_esmf at ultra-hires HOT 3
- F2000 initial conditions HOT 10
- NOANTHRO qualifier NOT working in ctsm5.2.005 for CLM51 physics (only for CLM50 or CLM60) HOT 2
- Fix or disable "Assign to High Priority project" workflow HOT 1
- Unable to install ctsm_pylib environment for mksurfdata_esmf in CTSM5.2.005 HOT 4
- Need to migrate our "classic" project boards to the new updated format by Aug/23rd
- bug in crop fire modeling HOT 6
- CTSM PPE prep work HOT 1
- Turn on Leung_2024 dust emission scheme by default for clm6_0
- Are these checks needed anymore? HOT 2
- Historical configuration for CLM6 HOT 6
- Quick start wiki not accurate for git-fleximod HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ctsm.