ERS_D_Ld5.f19_g16.I2000Clm50BgcCruGs run FAIL (intel) #322
Comments
|
I'm noticing that the other "old" terms are initialized/zero'd prior to the call of NitrogenAllocation() on line 368, except for the PNstoreold, which may be the offending uninitialized term. edit: PNStoreold is not initialized as far as I can tell. pinging @xuchongang |
|
I tried this on cheyenne and it worked there. @rgknox what version of intel is lawrencium running? I'll try it on hobart also... PASS ERS_D_Ld5.f19_g16.I2000Clm50BgcCruGs.cheyenne_intel.clm-default CREATE_NEWCASE |
|
@rgknox is this still an issue? |
|
As far as I can tell, PNStoreold, is still uninitialized. This is still generating uninitialized errors on lawrencium. My test is on fates_next_api branch, which delayed behind master, but I checked the code in master and from all accounts the variable simply isn't given a value, anywhere. (can anyone confirm?) The offending test is: ERS_D_Ld5.f19_g16.I2000Clm50BgcCruGs I checked the machine file on lawrencium-lr3, we don't specify any zany compile options during debug. Module info: intel/2016.4.072 |
|
I agree that that looks like a bug. However, it looks like the offending line, and thus the offending but that appears to be overridden here before I checked the logic of the @ekluzek do you think we should run this by someone else for confirmation? |
|
If nobody objects to my fix, I'll fold it in to an upcoming tag. |
|
@billsacks that seems to be correct to me as well. @wwieder could you take a look at this as well? If possible we could contact Bardan and/or Chonggang as well. @wwieder should we bother with contacting them? This came in with the original version in clm4_5_1_r120. If it doesn't change answers it seems like we should go forward with this. Since, Nstore is local I don't see how it could change answers, but sometimes there's some strange interaction that you don't catch simply by looking at it. |
|
I see it the same way you do @billsacks. While I don't know that code well, logically speaking, Nstore is overwritten later in the call-sequence before it is used anyway. |
|
Hello,
Sorry I've been traveling (and still at a meeting this week). I'm not
really following the thread, what would you like me to look at, Erik?
…On Fri, Oct 5, 2018 at 11:21 AM Erik Kluzek ***@***.***> wrote:
@billsacks <https://github.com/billsacks> that seems to be correct to me
as well. @wwieder <https://github.com/wwieder> could you take a look at
this as well? If possible we could contact Bardan and/or Chonggang as well.
@wwieder <https://github.com/wwieder> should we bother with contacting
them? This came in with the original version in clm4_5_1_r120. If it
doesn't change answers it seems like we should go forward with this. Since,
Nstore is local I don't see how it could change answers, but sometimes
there's some strange interaction that you don't catch simply by looking at
it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#322 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AHqLJAPKRenJV3FLFchOAb7K8PEQRJ16ks5uh5UogaJpZM4SrG7v>
.
--
Will Wieder
Project Scientist
CGD, NCAR
303-497-1352
|
|
Hi @wwieder I'm wondering if you can take a look at LunaMod.F90 specifically, the calculation of Nstore in subroutine NitrogenAllocation. It gets set near the top and then changed inside the "do while" loop. I suppose if the "do while" isn't executed you would need that initial setting, so maybe that's why it's there. But, why is it different than the other calculation? And is it possible for the do while NOT to be executed? Another question is if we need to bring someone else into the conversation? |
|
I can take a look this evening, but it may be more effective to bring
Chonggang into the discussion, as I haven't spent much time looking at or
thinking about what LUNA is actually doing.
…On Mon, Oct 8, 2018 at 10:22 AM Erik Kluzek ***@***.***> wrote:
Hi @wwieder <https://github.com/wwieder> I'm wondering if you can take a
look at LunaMod.F90 specifically, the calculation of Nstore in subroutine
NitrogenAllocation. It gets set near the top and then changed inside the
"do while" loop. I suppose if the "do while" isn't executed you would need
that initial setting, so maybe that's why it's there. But, why is it
different than the other calculation? And is it possible for the do while
NOT to be executed? Another question is if we need to bring someone else
into the conversation?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#322 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AHqLJCvVj9edAoU-ZAbj-OZu1v8-ZT-Rks5ui3u-gaJpZM4SrG7v>
.
--
Will Wieder
Project Scientist
CGD, NCAR
303-497-1352
|
|
This does seems a bug to me. There are too solutions to me. The first one is to delete the line as suggested by @billsacks and the second one is to put a initialization to set PNstoreold=0 at https://github.com/ESCOMP/ctsm/blob/b0439495b404c37ca8ef7c3e5252485c2d35e034/src/biogeophys/LunaMod.F90#L363. |
|
Thanks for the reply. I'll go ahead and delete the line since, from my and @rgknox 's analysis, it isn't needed. |
Miscellaneous minor, bit-for-bit bug fixes Four miscellaneous minor, bit-for-bit bug fixes: (1) Py3 pylint check and address cime issue ESMCI/cime#2822 (from Jim Edwards: #526) (2) Change uppercase DEBUG variables to lowercase debug (requested by Jim Edwards to avoid conflicting with the DEBUG CPP token) (Fixes #534) (3) Remove unnecessary line of code in LunaMod.F90 that was causing problems with some compilers due to an uninitialized variable (Fixes #322) (4) Add r8 to 0 constant to fix build issue with XLF compiler (from Jim Edwards: #531)
This initial setting of Nstore was problematic because it referenced the uninitialized PNstoreold variable. From some analysis, it looks like Nstore is always overwritten before it's referenced, so it's safe to just remove this line, along with the now-unnecessary PNstoreold subroutine argument. Fixes ESCOMP#322
From dev014 & dev015: CMIP6 compset modifiers, output usermods & fixes
Bring in all changes from ctsm1.0.dev014 and ctsm1.0.dev015:
From ctsm1.0.dev015:
(1) Support %BGC-CROP-CMIP6DECK and %BGC-CROP-CMIP6WACCMDECK compset
modifiers, so that we can turn on the necessary options
(output-related and others) via new CMIP6-specific compsets.
(2) Turn on carbon isotopes in CMIP6 runs (from Erik Kluzek)
(3) Remove setting of CCSM_BGC=CO2A in the cmip6 usermods
(4) Add usermods directories for getting typical extra output that's
wanted in many cases: output_crop, output_crop_highfreq, output_bgc,
output_bgc_highfreq, output_sp, and output_sp_highfreq. These can be
enabled by adding something like '--user-mods-dir output_crop' on
the create_newcase line (that short-hand works for an I compset; for
F or B compsets, you need to provide the full path to the usermod
directory).
(4) Allow holes in the number of history tapes. Holes are cases where,
for example, we have h0, h1 and h3 tapes, but no h2 tape (because
there are no fields on the h2 tape). (This is needed for (3).)
(5) Fix reading and writing of 1-d logical global arrays. This fixes
#24 for real (rather than just preventing an attempt to
read/write 1-d logical arrays, as was done in the previous 'fix').
(6) Add C13_NBP and C14_NBP diagnostic fields (from Keith Oleson)
(7) Make a bunch of carbon isotope diagnostic fields inactive by default
(8) Don't allow interpolation (use_init_interp) from a case without
carbon isotopes to a case with carbon isotopes: Due to
#67, interpolation from a case
without carbon isotopes to a case with carbon isotopes yields
incorrect initialization values for the carbon isotopes. Now that
we're turning carbon isotopes on via some semi-out-of-the-box
usermods (for cmip6), it is becoming more important to check to make
sure someone doesn't shoot themselves in the foot this way.
(9) Add tests of the new output usermods as well as of the CMIP6 compset
modifiers
From ctsm1.0.dev014: Four miscellaneous minor, bit-for-bit bug fixes:
(1) Py3 pylint check and address cime issue ESMCI/cime#2822 (from Jim
Edwards: #526)
(2) Change uppercase DEBUG variables to lowercase debug (requested by
Jim Edwards to avoid conflicting with the DEBUG CPP token)
(Fixes #534)
(3) Remove unnecessary line of code in LunaMod.F90 that was causing
problems with some compilers due to an uninitialized variable
(Fixes #322)
(4) Add r8 to 0 constant to fix build issue with XLF compiler (from Jim
Edwards: #531)
This initial setting of Nstore was problematic because it referenced the uninitialized PNstoreold variable. From some analysis, it looks like Nstore is always overwritten before it's referenced, so it's safe to just remove this line, along with the now-unnecessary PNstoreold subroutine argument. Fixes ESCOMP#322
Miscellaneous minor, bit-for-bit bug fixes Four miscellaneous minor, bit-for-bit bug fixes: (1) Py3 pylint check and address cime issue ESMCI/cime#2822 (from Jim Edwards: ESCOMP#526) (2) Change uppercase DEBUG variables to lowercase debug (requested by Jim Edwards to avoid conflicting with the DEBUG CPP token) (Fixes ESCOMP#534) (3) Remove unnecessary line of code in LunaMod.F90 that was causing problems with some compilers due to an uninitialized variable (Fixes ESCOMP#322) (4) Add r8 to 0 constant to fix build issue with XLF compiler (from Jim Edwards: ESCOMP#531)
This initial setting of Nstore was problematic because it referenced the uninitialized PNstoreold variable. From some analysis, it looks like Nstore is always overwritten before it's referenced, so it's safe to just remove this line, along with the now-unnecessary PNstoreold subroutine argument. Fixes ESCOMP#322
From dev014 & dev015: CMIP6 compset modifiers, output usermods & fixes
Bring in all changes from ctsm1.0.dev014 and ctsm1.0.dev015:
From ctsm1.0.dev015:
(1) Support %BGC-CROP-CMIP6DECK and %BGC-CROP-CMIP6WACCMDECK compset
modifiers, so that we can turn on the necessary options
(output-related and others) via new CMIP6-specific compsets.
(2) Turn on carbon isotopes in CMIP6 runs (from Erik Kluzek)
(3) Remove setting of CCSM_BGC=CO2A in the cmip6 usermods
(4) Add usermods directories for getting typical extra output that's
wanted in many cases: output_crop, output_crop_highfreq, output_bgc,
output_bgc_highfreq, output_sp, and output_sp_highfreq. These can be
enabled by adding something like '--user-mods-dir output_crop' on
the create_newcase line (that short-hand works for an I compset; for
F or B compsets, you need to provide the full path to the usermod
directory).
(4) Allow holes in the number of history tapes. Holes are cases where,
for example, we have h0, h1 and h3 tapes, but no h2 tape (because
there are no fields on the h2 tape). (This is needed for (3).)
(5) Fix reading and writing of 1-d logical global arrays. This fixes
ESCOMP#24 for real (rather than just preventing an attempt to
read/write 1-d logical arrays, as was done in the previous 'fix').
(6) Add C13_NBP and C14_NBP diagnostic fields (from Keith Oleson)
(7) Make a bunch of carbon isotope diagnostic fields inactive by default
(8) Don't allow interpolation (use_init_interp) from a case without
carbon isotopes to a case with carbon isotopes: Due to
ESCOMP#67, interpolation from a case
without carbon isotopes to a case with carbon isotopes yields
incorrect initialization values for the carbon isotopes. Now that
we're turning carbon isotopes on via some semi-out-of-the-box
usermods (for cmip6), it is becoming more important to check to make
sure someone doesn't shoot themselves in the foot this way.
(9) Add tests of the new output usermods as well as of the CMIP6 compset
modifiers
From ctsm1.0.dev014: Four miscellaneous minor, bit-for-bit bug fixes:
(1) Py3 pylint check and address cime issue ESMCI/cime#2822 (from Jim
Edwards: ESCOMP#526)
(2) Change uppercase DEBUG variables to lowercase debug (requested by
Jim Edwards to avoid conflicting with the DEBUG CPP token)
(Fixes ESCOMP#534)
(3) Remove unnecessary line of code in LunaMod.F90 that was causing
problems with some compilers due to an uninitialized variable
(Fixes ESCOMP#322)
(4) Add r8 to 0 constant to fix build issue with XLF compiler (from Jim
Edwards: ESCOMP#531)
This initial setting of Nstore was problematic because it referenced the uninitialized PNstoreold variable. From some analysis, it looks like Nstore is always overwritten before it's referenced, so it's safe to just remove this line, along with the now-unnecessary PNstoreold subroutine argument. Fixes ESCOMP#322
From dev014 & dev015: CMIP6 compset modifiers, output usermods & fixes
Bring in all changes from ctsm1.0.dev014 and ctsm1.0.dev015:
From ctsm1.0.dev015:
(1) Support %BGC-CROP-CMIP6DECK and %BGC-CROP-CMIP6WACCMDECK compset
modifiers, so that we can turn on the necessary options
(output-related and others) via new CMIP6-specific compsets.
(2) Turn on carbon isotopes in CMIP6 runs (from Erik Kluzek)
(3) Remove setting of CCSM_BGC=CO2A in the cmip6 usermods
(4) Add usermods directories for getting typical extra output that's
wanted in many cases: output_crop, output_crop_highfreq, output_bgc,
output_bgc_highfreq, output_sp, and output_sp_highfreq. These can be
enabled by adding something like '--user-mods-dir output_crop' on
the create_newcase line (that short-hand works for an I compset; for
F or B compsets, you need to provide the full path to the usermod
directory).
(4) Allow holes in the number of history tapes. Holes are cases where,
for example, we have h0, h1 and h3 tapes, but no h2 tape (because
there are no fields on the h2 tape). (This is needed for (3).)
(5) Fix reading and writing of 1-d logical global arrays. This fixes
ESCOMP#24 for real (rather than just preventing an attempt to
read/write 1-d logical arrays, as was done in the previous 'fix').
(6) Add C13_NBP and C14_NBP diagnostic fields (from Keith Oleson)
(7) Make a bunch of carbon isotope diagnostic fields inactive by default
(8) Don't allow interpolation (use_init_interp) from a case without
carbon isotopes to a case with carbon isotopes: Due to
ESCOMP#67, interpolation from a case
without carbon isotopes to a case with carbon isotopes yields
incorrect initialization values for the carbon isotopes. Now that
we're turning carbon isotopes on via some semi-out-of-the-box
usermods (for cmip6), it is becoming more important to check to make
sure someone doesn't shoot themselves in the foot this way.
(9) Add tests of the new output usermods as well as of the CMIP6 compset
modifiers
From ctsm1.0.dev014: Four miscellaneous minor, bit-for-bit bug fixes:
(1) Py3 pylint check and address cime issue ESMCI/cime#2822 (from Jim
Edwards: ESCOMP#526)
(2) Change uppercase DEBUG variables to lowercase debug (requested by
Jim Edwards to avoid conflicting with the DEBUG CPP token)
(Fixes ESCOMP#534)
(3) Remove unnecessary line of code in LunaMod.F90 that was causing
problems with some compilers due to an uninitialized variable
(Fixes ESCOMP#322)
(4) Add r8 to 0 constant to fix build issue with XLF compiler (from Jim
Edwards: ESCOMP#531)
I generated this FAIL as part of the FATES developer test suite. It seems to finish initializing MOSART, and then fails while initializing luna?
To reproduce:
Use the intel compiler ('m using Lawrencium, lr3 partition, intel/2016.4.072).
./create_test ERS_D_Ld5.f19_g16.I2000Clm50BgcCruGs.${MACH}.clm-default
Error:
Tested Hash: fc7d5c2 (based off of f167e9c with only test generation modifications).
Code:
Looks like the offending line is 851 of biogeophys/LunaMod.F90
https://github.com/ESCOMP/ctsm/blob/master/src/biogeophys/LunaMod.F90#L851
The text was updated successfully, but these errors were encountered: