Use tau_* values on params file

[ekluzek]

Erik Kluzek < erik > - 2016-06-10 14:30:46 -0600
Bugzilla Id: 2320
Bugzilla CC: cdkoven, dlawren, rfisher,

The "tau_*" values are currently using the hardcoded values in SoilBiogeochemDecompCascadeBGCMod.F90 rather than the values on the params file. The values on the params file are read in -- but discarded. The issue seems to be that answers change when you read in from the params file, rather than doing the inverse that the code has. So if the values read in are the inverse then you can do the divide in the code and preserve answers.

  ! the belowground parameters from century
  tau_l1 = 1./18.5
  tau_l2_l3 = 1./4.9
  tau_s1 = 1./7.3
  tau_s2 = 1./0.2
  tau_s3 = 1./.0045

  ! century leaves wood decomposition rates open, within range of 0 - 0.5 yr^-1
  tau_cwd  = 1./0.3

  ! Todo:  FIX(SPM,032414) - the explicit divide gives different results than when that
  ! value is placed in the parameters netcdf file.  To get bfb, keep the 
  ! divide in source.

  !tau_l1 = params_inst%tau_l1_bgc
  !tau_l2_l3 = params_inst%tau_l2_l3_bgc
  !tau_s1 = params_inst%tau_s1_bgc
  !tau_s2 = params_inst%tau_s2_bgc
  !tau_s3 = params_inst%tau_s3_bgc

  !set turnover rate of coarse woody debris
  !tau_cwd = params_inst%tau_cwd_bgc

There are similar issues in SoilBiogeochemLittVertTranspMod.F90 and in biogeochem/ch4Mod.F90. They are documented with the following type of comment in the code...

! FIX(FIX(SPM,032414),032414) can't be read off of param file. not bfb since it is a divide

So this means there are several variables on the params file that get read in and then ignored.

[ekluzek]

Erik Kluzek < erik > - 2016-06-10 14:48:41 -0600

The list of variables read and ignored seems to be:

vmax_ch4_oxid (divide by seconds per hour)
k_m (don't see why this one is a problem) *
k_m_o2 (don't see why this one is a problem) *
k_m_unsat (divide by 10?) *
vmax_oxid_unsat (divide by seconds per hour divided by 10) *
unsat_aere_ratio (divide by 0.3? -- it's 0.05_r8 / 0.3_r8) *
tau_l1_bgc (do inverse)
tau_l2_l3_bgc (do inverse)
tau_s1_bgc (do inverse)
tau_s2_bgc (do inverse)
tau_s3_bgc (do inverse)
tau_cwd_bgc (do inverse)
som_diffus (divide by seconds per year)
cryoturb_diffusion_k (divide by seconds per year)

some of these may just need to be set to a higher precision in the params file. Making sure the value put on the file is double precision, may resolve the bit-for-bit issues.

[ekluzek]

Erik Kluzek < erik > - 2017-09-11 16:21:00 -0600

Looking at the variables in double precision I see there are a few bits left off the params file for example...

tau_l1 = 0.05405405405406
tau_l2_l3 = 0.2040816326530612
ta_s3 = 222.2222222222222
tau_cwd = 3.333333333333333

other variables have the same issue, but show up in very low significant digits. So this should be able to be made exact.

[ekluzek]

Erik Kluzek < erik > - 2017-09-14 14:42:38 -0600

Using the params files:
lnd/clm2/paramdata/clm5_params.c170913.nc and lnd/clm2/paramdata/clm_params.c170913.nc

I get bit-for-bit results when using the values on the params files above. I have this on a branch and will bring it to the trunk.

[ekluzek]

This is still a problem. It's an issue for anyone who is working with the params file and doing parameter estimation. Possibly they could find that changing these variables on the params file doesn't cause any changes and not realize it's because the values from the file are overwritten.

[billsacks]

@ekluzek you said you have the fix for this on a branch; is that correct? (I'm reviewing some old bugs.)

[ekluzek]

It looks like @olyson tackled this problem and has a fix for it on the hardcodep branch that will be coming to master.