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

release-clm5.0.30 merging with ctsm1.0.dev093 prior to fates_next_api merge #1

Closed
glemieux opened this issue May 28, 2020 · 10 comments
Closed
Assignees

Comments

@glemieux
Copy link
Owner

glemieux commented May 28, 2020

Creating this issue as a place to discuss issues with merging release-clm5.0.30 and ctsm1.0.dev093 as noted here:
ESCOMP#1008 (comment)

Deconflicting branch is https://github.com/glemieux/ctsm/tree/release-clm5.0.30-ctsm1.0.dev093

@glemieux glemieux self-assigned this May 28, 2020
@glemieux
Copy link
Owner Author

@ekluzek doing a diff on the two branches I notice that bld/configure is not included in the dev093 tag on master. Did this code get renamed or moved elsewhere?

@ekluzek
Copy link
Collaborator

ekluzek commented May 28, 2020

It was removed on master and is unneeded.

@glemieux
Copy link
Owner Author

glemieux commented May 29, 2020

@ekluzek the following exists in the release branch version of the code. Should it be included in the merge up to ctsm1.0.dev093? Note I have not corrected the change from waterflux_inst% to water_inst%waterfluxbulk_inst% yet:

! NOTE(wjs, 2018-12-05) Similarly, it's not entirely appropriate to put
! qflx_runoff_rain_to_snow_conversion_col into qflx_qrgwl_col, since again, this
! is generated over landunits other than glaciers, wetlands and lakes. I'm
! putting it in qflx_qrgwl_col partly because glacier landunits are typically
! the primary source of this flux, and partly just because I'm not sure where
! else to put it.
waterflux_inst%qflx_qrgwl_col(c) = waterflux_inst%qflx_qrgwl_col(c) + &
waterflux_inst%qflx_runoff_rain_to_snow_conversion_col(c)

The commit for this code is: ESCOMP@71b3a0a

@ekluzek
Copy link
Collaborator

ekluzek commented May 29, 2020

glacier_region_rain_to_snow_behavior was something that was JUST put on the release branch. So we should remove it in this update of fates_next_api, so that fates_next_api will be like what's on master.

@glemieux
Copy link
Owner Author

glemieux commented May 29, 2020

glacier_region_rain_to_snow_behavior was something that was JUST put on the release branch. So we should remove it in this update of fates_next_api, so that fates_next_api will be like what's on master

Does that mean that everything in the above commit should be reverted: ESCOMP@71b3a0a? Including things like rain_to_snow_runoff?

@ekluzek
Copy link
Collaborator

ekluzek commented May 29, 2020

Does that mean that everything in the above commit should be removed: ESCOMP@71b3a0a?

Yes.

release-clm5.0.15 was skipped on master (the above commit you point to). I don't see anything else that's like that (there was a cime update that doesn't apply for master in release-clm5.0.19, but nothing like this other commit)

glemieux pushed a commit that referenced this issue Jun 5, 2020
…update

Updating externals_clm.cfg to point to the associated fates tag
@glemieux
Copy link
Owner Author

This branch passes regression test comparisons using clm_short now. Results are here:

/glade/u/home/glemieux/scratch/ctsm-tests/tests_ctsmdev-release-merge

@glemieux
Copy link
Owner Author

glemieux commented Jun 18, 2020

Tested this branch last weekend with full aux_clm regression suite:

/glade/u/home/glemieux/scratch/ctsm-tests/tests_ctsmdev-release-merge-fullregression

I'm getting the following DIFF fails:

    FAIL ERP_P36x2_Lm13.f10_f10_musgs.IHistClm50Bgc.cheyenne_gnu.clm-monthly BASELINE ctsm1.0.dev093: DIFF
    FAIL ERS_Ly3_Mmpi-serial.1x1_smallvilleIA.IHistClm50BgcCropQianGs.cheyenne_gnu.clm-cropMonthOutput BASELINE ctsm1.0.dev093: DIFF
    FAIL SMS_Ly1_Mmpi-serial.1x1_brazil.IHistClm50BgcQianGs.cheyenne_gnu.clm-output_bgc_highfreq BASELINE ctsm1.0.dev093: DIFF
    FAIL ERP_D_Ld3.f09_g17.I2000Clm50SpGs.cheyenne_intel.clm-prescribed BASELINE ctsm1.0.dev093: DIFF
    FAIL ERP_D_Ld5.f10_f10_musgs.IHistClm50BgcCrop.cheyenne_intel.clm-allActive BASELINE ctsm1.0.dev093: DIFF
    FAIL ERP_Ly3_P72x2.f10_f10_musgs.IHistClm50BgcCrop.cheyenne_intel.clm-cropMonthOutput BASELINE ctsm1.0.dev093: DIFF
    FAIL ERP_P36x2_Lm13.f10_f10_musgs.IHistClm50Bgc.cheyenne_intel.clm-monthly BASELINE ctsm1.0.dev093: DIFF
    FAIL ERS_Ly3_P72x2.f10_f10_musgs.IHistClm50BgcCropG.cheyenne_intel.clm-cropMonthOutput BASELINE ctsm1.0.dev093: DIFF
    FAIL ERS_Ly5_P144x1.f10_f10_musgs.IHistClm50BgcCrop.cheyenne_intel.clm-cropMonthOutput BASELINE ctsm1.0.dev093: DIFF
    FAIL ERS_Ly5_P72x1.f10_f10_musgs.IHistClm45BgcCrop.cheyenne_intel.clm-cropMonthOutput BASELINE ctsm1.0.dev093: DIFF
    FAIL ERS_Ly6_Mmpi-serial.1x1_smallvilleIA.IHistClm50BgcCropQianGs.cheyenne_intel.clm-cropMonthOutput BASELINE ctsm1.0.dev093: DIFF
    FAIL LCISO_Lm13.f10_f10_musgs.IHistClm50BgcCrop.cheyenne_intel.clm-ciso_monthly BASELINE ctsm1.0.dev093: DIFF
    FAIL SMS_D_Ly6_Mmpi-serial.1x1_smallvilleIA.IHistClm45BgcCropQianGs.cheyenne_intel.clm-cropMonthOutput BASELINE ctsm1.0.dev093: DIFF

Note that all the DIFF failures, except one, are for the compsets IHistClm all of which also failed NLCOMP. All NLCOMP failure are for this compset timeframe as well, although note that not all NLCOMP failures resulted in a DIFF failure (i.e. some PASSED baseline check).

All but one of the IHistClm DIFF failures is a BgcCrop compset. This reminded me that there was an unresolved difference in the namelist_ctsm_default.xml that might be related? In the ctsm1.0.dev093 baseline the following lines have irrigate=.false:

clm4.5:

<init_interp_attributes sim_year="1850" use_cndv=".false." use_fates=".false." lnd_tuning_mode="clm4_5_cam6.0"
>hgrid=0.9x1.25 maxpft=79 mask=gx1v7 use_cn=.true. use_nitrif_denitrif=.true. use_vertsoilc=.true. use_crop=.true. irrigate=.true. glc_nec=10
</init_interp_attributes>

clm5.0:
<init_interp_attributes sim_year="1850" use_cndv=".false." use_fates=".false." lnd_tuning_mode="clm5_0_cam6.0"
>hgrid=0.9x1.25 maxpft=79 mask=gx1v7 use_cn=.true. use_nitrif_denitrif=.true. use_vertsoilc=.true. use_crop=.true. irrigate=.true. glc_nec=10
</init_interp_attributes>

<finidat hgrid="0.9x1.25" maxpft="79" mask="gx1v7" use_cn=".true." use_cndv=".false." use_fates=".false."
ic_ymd="18500101" use_nitrif_denitrif=".true." use_vertsoilc=".true." sim_year="1850"
ic_tod="0" glc_nec="10" use_crop=".true." irrigate=".true." use_init_interp=".true."
lnd_tuning_mode="clm4_5_cam6.0"
>lnd/clm2/initdata_map/clmi.B1850.0161-01-01.0.9x1.25_gx1v7_simyr1850_c190111.nc
</finidat>

I'm going to locally edit the namelist file and see if this clears that subset of DIFF errors.

UPDATE: running with the local edit to irrigation in the namelist file result in the same DIFF errors. Did result in a new, unexpected RUN fail though. Suggests to me that irrigation difference is fine.

@glemieux
Copy link
Owner Author

glemieux commented Jun 18, 2020

Still waiting on the irrigate=.false. test check to run. I went and looked at the NLCOMP failures to see what was being reported in TestStatus.log. @ekluzek I'm seeing the following NLCOMP difference in the above list of DIFF fails that also have NLCOMP differences:

    Differences in namelist 'ndepdyn_nml':
    BASE: ndep_taxmode = 'cycle'
    COMP: ndep_taxmode = 'extend'
    BASE: stream_year_last_ndep = 2005
    COMP: stream_year_last_ndep = 2015

I'm not familiar with where the ndepdyn_nml contents get set. Do you think this update is acceptable?

UPDATE: I see it being initialized with extend via ndep_init in ndepStreamMod.F90 and some settings in user_default_ctsm.xml, but they match the ctsm1.0.dev093, so I'm guessing this is happening somewhere else that I'm not seeing.

I should note that the following only have the difference in ndep_taxmode and not a difference in stream_year_last_ndep:

ERS_Ly5_P72x1.f10_f10_musgs.IHistClm45BgcCrop.cheyenne_intel.clm-cropMonthOutput
SMS_D_Ly6_Mmpi-serial.1x1_smallvilleIA.IHistClm45BgcCropQianGs.cheyenne_intel.clm-cropMonthOutput

glemieux pushed a commit that referenced this issue Jul 23, 2020
Reinstate hlm_model_day fix from CTSM PR 820
@glemieux
Copy link
Owner Author

Closing issue as the update has been complete via rebase.

glemieux pushed a commit that referenced this issue Aug 28, 2020
glemieux pushed a commit that referenced this issue Aug 28, 2020
update my ctsm fork to latest
glemieux pushed a commit that referenced this issue Jan 12, 2021
Changes to review of dynlakes_master_notools

Response to review of Pull Request ESCOMP#1109:
including removal of lake_heat variable, update of surfrd_lakemask module and clean up of comments.
glemieux pushed a commit that referenced this issue Aug 16, 2021
glemieux pushed a commit that referenced this issue Mar 4, 2022
glemieux pushed a commit that referenced this issue Mar 4, 2022
This reverts commit eac83c1, reversing
changes made to 84e970f.
glemieux pushed a commit that referenced this issue 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 issue May 9, 2024
Update build namelist checks for valid landuse v2 mode combinations
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

No branches or pull requests

2 participants