• Version: VIC.5.0.1 develop branch
• Compiler: gcc 5.4.0
• Operating system: ubuntu 16.04.9
• Model settings: image driver
• Problem summary:
  When using parameter files that I have generated from scratch, various states and fluxes get weird values that fairly quickly lead to nans. This doesn't happen with parameter files that I've generated with tonic from the Livneh et al (2015) ascii soil/veg/snowband parameter files.

I believe that the problem is caused by a combination of how I created my parameter files and some potentially missing/bad logic in VIC (and tonic). But when I try to fix my parameter files to make them more amenable to VIC, VIC still has trouble. I am not sure whether it's because I haven't succeeding in fixing my parameter files, or whether there's some other problem occurring. I could use some advice and/or help brainstorming for solutions here...

More detail:
My new parameter files generated from scratch differ from the tonic-generated files in a few ways:

• for "vegetation library" parameters and root zone parameters, tonic sets them to "valid" values (the same constant value) in all classes in all grid cells, regardless of whether those classes are actually present in the grid cell (i,e, Cv[v] >= 0). In my parameters, I only defined them where Cv[v] > 0, and set them to missing where the vegetation class is not present (Cv[v] == 0).
• tonic creates an extra bare soil tile in cells where the vegetated tile areas sum up to less than 1 (Cv_sum < 1); but does NOT increment Nveg to reflect the extra tile (i.e., Nveg < Nnonzero, where Nnonzero is the number of tiles for which Cv[v] > 0). In my parameters, the tile areas always reflect exactly what is present in the land cover map; Cv_sum always == 1 (except for numerical error); and Nveg == Nnonzero.
• tonic parameter files define all floating point variables as type double. I defined mine as float to save space, since I didn't need the precision.

In vic_run(), I saw that bad values (they looked a lot like the missing value I'd given them in my parameter file) of veg parameters such as trunk_ratio were being passed to CalcAerodynamic(). This could certainly explain why the tonic parameter files didn't cause problems (since even invalid tiles have valid parameter values in tonic-generated parameter files). To verify that missing values from invalid tiles were getting passed, I replaced those values in the parameter file with an arbitrary value (again, only where Cv[v] == 0), and these values showed up being passed to CalcAerodynamic().

As for why these garbage values were being used, I hypothesized that VIC was somehow mistaking zero-area tiles for valid tiles. Looking at the code, in get_global_domain(), VIC assigns nv_active to Nveg+1, where Nveg is the value from the parameter file; then in vic_alloc() it allocates nv_active tiles to veg_con and calls make_all_vars() with nv_active-1, which allocates nv_active-1+1 tiles to veg_var, cell, etc. But then, vic_init() does its mapping between the all-classes-stored structure veg_con_map and the only-nonzero-classes structure veg_con by checking whether Cv > 0. Nveg is NOT involved in this mapping. My theory at the moment is that my single-precision Cv values might not look like 0 to VIC when VIC is interpreting them as doubles, thus causing the mapping to map invalid tiles to the veg_con structure.

However, I've tried changing Cv in my parameter file to double, and tried rounding all values to 6 digits of precision to ensure that 0s look like 0s. But it doesn't fix the problem. So, if I've not properly zeroed the 0s this way, I could definitely use help getting that to work correctly (my python skills are still not at the level of the UW lab).

But I don't know for sure if that's what happened - maybe I did succeed in zeroing out the 0s (it looked that way in a python session), and maybe something else is causing the problem in VIC.

Regardless, I can also see that VIC and tonic might benefit from improved code to counter these problems. Tonic's inconsistent incrementing of Nveg seems dangerous. In VIC, we could easily implement a check on whether the total number of tiles with Cv[v] > 0 actually equals Nveg - if not, it could give the user a helpful error message so that the user knows exactly what the problem is.

Also, I think tonic's assignment of valid parameter values to cell/class combinations where the classes are not present is a bad policy, since if VIC for some other reason were to accidentally assign invalid tiles, the error would not be caught (the parameters would be physically reasonable, just wrong).

Any thoughts/advice on this would be greatly appreciated. I need to get my simulations going ASAP!