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

dynamic root code divides by 0 #38

Closed
billsacks opened this issue Dec 16, 2017 · 8 comments
Closed

dynamic root code divides by 0 #38

billsacks opened this issue Dec 16, 2017 · 8 comments
Labels
closed: wontfix We won't fix this issue, because it would be too difficult and/or isn't important enough to fix type: bug something is working incorrectly

Comments

@billsacks
Copy link
Member

Bill Sacks < sacks@ucar.edu > - 2015-10-31 05:15:52 -0600
Bugzilla Id: 2237
Bugzilla CC: andre@ucar.edu, dlawren@ucar.edu, gbisht@lbl.gov, rfisher@ucar.edu,

Runs that activate both use_dynroot and crop crash in the first time step if run in debug mode. This is due to a divide by 0 error in this line in CNRootDynMod:

                root_depth(p) = max(zi(c,2), min(hui(p)/huigrain(p)* root_dmx(ivt(p)), root_dmx(ivt(p))))

huigrain(p) can sometimes be 0; in the one case I looked at, hui was also 0. Also, in the first timestep of a cold start, huigrain is NaN.

So this needs:

(1) initialization of huigrain in cold start so that it isn't NaN: it should probably be initialized to 0

(2) appropriate handling of the case when huigrain = 0

@billsacks billsacks added this to the clm5 milestone Dec 16, 2017
@billsacks
Copy link
Member Author

billsacks commented Dec 16, 2017

Erik Kluzek < erik@ucar.edu > - 2015-11-18 14:29:31 -0700

The fix that Beth Drewniak gave us for this was to initialize huigrain to zero everywhere, and then...

Index: components/clm/src/biogeochem/CNRootDynMod.F90
===================================================================
--- components/clm/src/biogeochem/CNRootDynMod.F90	(.../branch_tags/fun20exp_tags/fun20exp_n08_fun2_0_n09clm4_5_6_r153)	(revision 75190)
+++ components/clm/src/biogeochem/CNRootDynMod.F90	(.../branches/fun20exp)	(revision 75190)
@@ -134,7 +134,9 @@
             c = pcolumn(p)
             if (ivt(p) /= noveg) then
                 if((ivt(p)) >= npcropmin)then !skip generic crop types
-                    root_depth(p) = max(zi(c,2), min(hui(p)/huigrain(p)* root_dmx(ivt(p)), root_dmx(ivt(p))))
+                    if(huigrain(p) > 0._r8)then
+                        root_depth(p) = max(zi(c,2), min(hui(p)/huigrain(p)* root_dmx(ivt(p)), root_dmx(ivt(p))))
+                    end if
                 else
                 ! this can be changed to any depth (i.e. the maximum soil depth)
                     root_depth(p) = zi(c,nlevsoi)

@billsacks
Copy link
Member Author

Bill Sacks < sacks@ucar.edu > - 2015-11-18 14:52:50 -0700

Shouldn't there be an 'else' clause here, so that root_depth gets set explicitly if huigrain(p) == 0? Or is the intention really that it remains at whatever value it was at in the previous time step?

@billsacks
Copy link
Member Author

Bill Sacks < sacks@ucar.edu > - 2015-11-23 12:33:10 -0700

Gautam's suggestion to the 'else', approved by Beth, is:

How about adding root_depth(bounds%begp:bounds%endp) = 0._r8 on CNRootDynMod.F90#L111?

@billsacks
Copy link
Member Author

Bill Sacks < sacks@ucar.edu > - 2015-11-23 12:35:28 -0700

Oops, I forgot to finish Gautam's suggestion:

Then, you can get rid of the 'else' clause at line CNRootDynMod.F90#L130.

@billsacks
Copy link
Member Author

Bill Sacks < sacks@ucar.edu > - 2015-11-23 12:39:27 -0700

However, in response to comment 3: Based on the performance impact we have seen for CNZero, I am coming to feel that we should avoid code like:

root_depth(bounds%begp:bounds%endp) = 0._r8

instead either (a) initializing this in the loop over the filter (i.e., setting root_depth(p) = 0._r8 before the conditionals), or (b) keeping / adding explicit 'else' clauses to ensure it is set to something for any path through the conditionals.

This isn't a big deal for this particular change, but is something we should think about in general: As we have seen from CNZero, when you add up the total time we spend zeroing quantities, it amounts to a significant fraction of CLM run time.

@billsacks
Copy link
Member Author

Erik Kluzek < erik@ucar.edu > - 2015-11-23 13:13:54 -0700

The first part of this was completed in clm4_5_6_r155.

@billsacks billsacks added the type: bug something is working incorrectly label Feb 9, 2018
@billsacks billsacks removed this from the clm5 milestone Nov 7, 2018
@billsacks billsacks added the tag: next this should get some attention in the next week or two label Jul 8, 2019
@billsacks
Copy link
Member Author

billsacks commented Jul 8, 2019

It looks like the fix from #38 (comment) was applied, but the suggested else clause still hasn't been put in. (The same seems true in E3SM.) So, if huigrain goes to 0, I believe root_depth remains at its previous value. The one place where I can find huigrain being set to 0 is here:

https://github.com/ESCOMP/ctsm/blob/57adf1ed1f3f5d4b4881277734c6d4b67a392c64/src/biogeochem/CNPhenologyMod.F90#L2233-L2236

I'm not sure whether we should leave things as is (because root depth may not matter in cases where huigrain has been set to 0 anyway), or do the (fairly easy) suggestion above (adding an else clause).

@billsacks
Copy link
Member Author

Closing as a wontfix because dynamic roots needs some work anyway.

@billsacks billsacks added closed: wontfix We won't fix this issue, because it would be too difficult and/or isn't important enough to fix and removed tag: next this should get some attention in the next week or two labels Jul 8, 2019
samsrabin pushed a commit to samsrabin/CTSM that referenced this issue May 3, 2024
remove shr_mpi_mod
Description of changes

Remove shr_mpi_mod and replace with ESMF_VM operations.
Specific notes

Contributors other than yourself, if any:

CDEPS Issues Fixed: ESCOMP#38

Are there dependencies on other component PRs (if so list):

Are changes expected to change answers: bfb
Any User Interface Changes (namelist or namelist defaults changes): no

Testing performed (e.g. aux_cdeps, CESM prealpha, etc): aux_cdeps on cheyenne intel, all pass.
swensosc pushed a commit to swensosc/ctsm that referenced this issue Jun 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed: wontfix We won't fix this issue, because it would be too difficult and/or isn't important enough to fix type: bug something is working incorrectly
Projects
None yet
Development

No branches or pull requests

1 participant