Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

added timing calls to all subroutines in clmfates_interfaceMod.F90 #2

Merged
merged 1 commit into from
Aug 25, 2020

Conversation

ckoven
Copy link

@ckoven ckoven commented Aug 14, 2020

Description of changes

per ESCOMP#1076, understanding all the costs of fates is needed to focus efforts on what optimizations to focus on. this adds calls to the timing infrastructure for each of the subroutines in clmfates_interfaceMod as a first step towards understanding the problem.

Specific notes

Contributors other than yourself, if any:
discussed with @rgknox

CTSM Issues Fixed (include github issue #):

Are answers expected to change (and if so in what way)? no

Any User Interface Changes (namelist or namelist defaults changes)? no

Testing performed, if any:

none yet

(List what testing you did to show your changes worked as expected)
(This can be manual testing or running of the different test suites)
(Documentation on system testing is here: https://github.com/ESCOMP/ctsm/wiki/System-Testing-Guide)
(aux_clm on cheyenne for gnu/pgi and hobart for gnu/pgi/nag is the standard for tags on master)

NOTE: Be sure to check your Coding style against the standard:
https://github.com/ESCOMP/ctsm/wiki/CTSM-coding-guidelines

@rgknox
Copy link

rgknox commented Aug 14, 2020

glorious

@glemieux
Copy link
Owner

Reminder to future self: make sure to increment the TIMER_LEVEL in env_run.xml to make sure that the timing routine will go deep enough into the code stack to enable the fates timers. Details are here: http://esmci.github.io/cime/versions/master/html/users_guide/timers.html?highlight=timing

@glemieux
Copy link
Owner

All expected tests passed B4B:

/glade/u/home/glemieux/scratch/ctsm-tests/tests_fates-timing-merge

Note that there was a weird error that I believe was just a hiccup with cheyenne. All the ERP tests failed setup initially. Running the tests individually using run_sys_tests was successful, but only if I didn't specify a subdirectory for the test output. If I see this error again, I'll post an issue on the official ctsm repo.

@glemieux glemieux merged commit e467920 into glemieux:fates_main_api Aug 25, 2020
glemieux pushed a commit that referenced this pull request Aug 28, 2020
glemieux pushed a commit that referenced this pull request Sep 25, 2020
Cleanup typo and empty logic set
glemieux pushed a commit that referenced this pull request Jan 12, 2021
Adjust ice to liquid density in ice mass calculation

Adjust ice to liquid density in ice mass calculation, as lake layer is not adjusted for change in density.
glemieux pushed a commit that referenced this pull request Jul 20, 2021
glemieux pushed a commit that referenced this pull request Nov 23, 2021
LILACSMOKE test: point to a still-existing Macros.make
glemieux pushed a commit that referenced this pull request Mar 4, 2022
glemieux pushed a commit that referenced this pull request May 3, 2022
Ideally we would do year-2000 tests to have more crop cover and thus
potentially be more useful tests. However, there are problems running a
year-2000 ciso test with crop. These problems exist even with an SMS
test on master:

I tried tests like
SMS_Ly1_P72x1.f10_f10_mg37.I2000Clm45BgcCrop.cheyenne_gnu.clm-ciso--clm-cropMonthOutput,
but both debug & non-debug, intel & gnu versions.

Debug tests fail like this (from SMS_D_Ly1_P72x1.f10_f10_mg37.I2000Clm45BgcCrop.cheyenne_gnu.clm-ciso--clm-cropMonthOutput):

30:Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.
30:
30:Backtrace for this error:
13:
13:Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.
13:
13:Backtrace for this error:
13:#0  0x2b9d1acc4aff in ???
30:#0  0x2b9d1acc4aff in ???
13:#1  0xf63fff in cisofluxcalc
13:     at /glade/work/sacks/ctsm_code/ctsm/src/biogeochem/CNCIsoFluxMod.F90:1555
30:#1  0xf63fff in cisofluxcalc
30:     at /glade/work/sacks/ctsm_code/ctsm/src/biogeochem/CNCIsoFluxMod.F90:1555
30:#2  0xf6b489 in __cncisofluxmod_MOD_cisoflux1
30:     at /glade/work/sacks/ctsm_code/ctsm/src/biogeochem/CNCIsoFluxMod.F90:153
13:#2  0xf6b489 in __cncisofluxmod_MOD_cisoflux1
13:     at /glade/work/sacks/ctsm_code/ctsm/src/biogeochem/CNCIsoFluxMod.F90:153
13:#3  0xe45657 in __cndrivermod_MOD_cndrivernoleaching
13:     at /glade/work/sacks/ctsm_code/ctsm/src/biogeochem/CNDriverMod.F90:559
30:#3  0xe45657 in __cndrivermod_MOD_cndrivernoleaching
30:     at /glade/work/sacks/ctsm_code/ctsm/src/biogeochem/CNDriverMod.F90:559

An intel test dies in the same place.

Non-debug versions die like this (both for gnu and intel):

30: set_curr_delta ERROR: found unexpected non-zero delta mid-year
30: Dribbler name: hrv_xsmrpool_to_atm_c_13
30: i, delta =            2                       NaN
30: Start of time step date (yr, mon, day, tod) =         2000           1          15       57600
30: This indicates that some non-zero flux was generated at a time step
30: other than the first time step of the year, which this dribbler was told not to expect.
30: If this non-zero mid-year delta is expected, then you can suppress this error
30: by setting allows_non_annual_delta to .true. when constructing this dribbler.
30:iam = 30: local  gridcell index = 2
30:iam = 30: global gridcell index = 103
30:iam = 30: gridcell longitude    =  285.0000000
30:iam = 30: gridcell latitude     =  -10.0000000
30: ENDRUN:
30: ERROR: set_curr_delta: found unexpected non-zero delta mid-year: ERROR in /glade/work/sacks/ctsm_code/ctsm/src/utils/AnnualFluxDr
ibbler.F90 at line 276

So there is some issue with year-2000 ciso tests with crop. This issue
exists on master, for clm45 and clm50 tests. (e.g., for clm50, I tried
SMS_D_Ly1_P72x1.f10_f10_mg37.I2000Clm50BgcCrop.cheyenne_gnu.clm-ciso--clm-cropMonthOutput.)
glemieux pushed a commit that referenced this pull request May 23, 2024
…ation

Remove fates dependency on `do_harvest`
glemieux pushed a commit that referenced this pull request Aug 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants