VIC Home
What Is VIC?
How to Run VIC
Model Development
Downloads
Frequently Asked Questions
VIC Users Listserve

Frequently Asked Questions

Here are some commonly-asked questions and their answers. Another source of information is the VIC Users Listserve. If you join this listserve, you can post questions to the vic user community.

Contents:

1. Does VIC and/or the routing model run on Windows?
2. Is VIC available in Fortran?
3. Is the routing model available in C?
4. What are the hardware requirements for VIC and the routing model? Do they take advantage of parallel processing / can they run in a multi-threaded environment?
5. Are there any Matlab tools written for analyzing and/or plotting VIC results?
6. How can I save VIC's screen output in a file?
7. VIC runs fine in water-balance mode, but when I set FULL_ENERGY to TRUE, it crashes – why?
8. VIC reports that the energy balance failed to converge in snow_intercept, calc_atmos_energy_bal, calc_surf_energy_bal, or solve_T_profile - what can I do?
9. VIC 4.1.1 gives substantially different results from previous versions of VIC for surface temperature, albedo, and aerodynamic resistance, especially in winter. Why?
10. I don't see VIC 4.0.7 listed on this web site. Why?
11. Why does actual evapotranspiration (ET) sometimes exceed potential evapotranspiration (PET)?

Answers:

1. Does VIC and/or the routing model run on Windows?

   The VIC model and the routing model have been developed for use on LINUX and UNIX platforms. To use VIC and/or the routing model on a Windows platform, we suggest downloading a free UNIX emulator such as Cygwin and compiling/running these models within this emulator. Please do not ask us for help with installing or using Cygwin.

   
   
2. Is VIC available in Fortran?

   For the most part, no. In the past, there have been attempts to translate the model to Fortran, but these versions are far out of date, and we do not recommend using them.

   
   
3. Is the routing model available in C?

   For the most part, no. We do know of a version of the model written in C that is being tested by a group here at UW, but there are some discrepancies between it and the official Fortran version. When these are resolved, we may post the C version. If you would like to try the C version, with the caveat that it isn't exactly the same as the Fortran version, please send email to the VIC Administrator.

   
   
4. What are the hardware requirements for VIC and the routing model? Do they take advantage of parallel processing / can they run in a multi-threaded environment?

   VIC's code is not explicitly written for parallel processing. Nevertheless, VIC's design will allow you to implement a "poor man's parallelization". Because VIC simulates each grid cell independently of the others, you can break up your study domain into separate sub-domains (these could be sub-basins or simply any arbitrary grouping of grid cells) and simulate each of these sub-domains separately, in parallel (on different nodes of a cluster, for example). Dividing the domain into sub-domains and combining them again later should be fairly easy, since VIC's input forcings and output results are organized into one file per grid cell. All you need to do is create separate soil parameter files, one for each sub-domain (these can even be copies of the original whole-domain soil parameter file, with the appropriate grid cells given a "1" as the first value and all other grid cells given a "0"). You will also need to create separate global parameter files. These would all be identical save for the soil parameter file that they point to. Of course the routing model must access all grid cells in a single run, but it runs very quickly in comparison to the VIC run.

   VIC is very I/O intensive - by default it appends to the grid cell's output file at the end of every time step, although the more recent versions (4.0.6, 4.1.1) allow you to aggregate sub-daily results to a daily time step before writing them, thus cutting down the number of file writes.  Still, if you are running on a cluster that has many nodes but a common disk array with a small number of disk controllers, a performance bottleneck will occur in the writing of output files.  In this case (which we have here in our lab), the best thing to do is write the output locally (assuming the nodes have their own storage) during the simulation, and then at the end of each node's job, have the job copy all the output back to the common array in a single command, which will be much more efficient in terms of block sizes than VIC's single-record writing.

   On the other hand, VIC is not very memory-intensive, since it only stores the state of a single grid cell in memory at a given time. I don't know off hand how much memory is uses, though that would be a good statistic to measure.

   
   
5. Are there any Matlab tools written for analyzing and/or plotting VIC results?

   No, not here in the lab. Check the VIC Users Listserve.

   
   
6. How can I save VIC's screen output in a file?

   If you'd like to capture VIC's screen output in a log file, you can do (in C-shell):

   vicNl -g global_parameter_filename >& log.txt

   where

   global_parameter_filename = name of the global parameter file corresponding to your project.

   log.txt = name of a log file to contain VIC's screen output.

   This strategy also works for the routing model screen output.

   
   
7. VIC runs fine in water-balance mode, but when I set FULL_ENERGY to TRUE, it crashes – why?

   If you are running an older version of VIC (pre-4.1.1), one explanation might be that your soil parameter file has “nodata” values (e.g. -9999) for bubbling pressure, which is not needed for water balance runs. Bubbling pressure is necessary for energy-balance runs, but older versions of VIC did not check whether the values of bubbling pressure in the soil parameter file were valid. 4.1.1 does check and exits with an error message if bubbling pressure is not valid. If you need a quick-and-dirty way to generate values of bubbling pressure so that you can start an energy-balance run, you can use an approximate relationship between bubble and values of expt in your soil parameter file, derived by applying a linear regression to the values from Table 5.3.2 in Handbook of Hydrology and converting lambda to Brooks-Corey's n via Table 5.1.1 in Handbook of Hydrology.

   
   
8. VIC reports that the energy balance failed to converge in snow_intercept, calc_atmos_energy_bal, calc_surf_energy_bal, or solve_T_profile - what can I do?

   Failures to converge can arise for a number of reasons. Causes can include bad input parameters or forcings, poor choice of model timestep length, and instability of the model equations themselves. Here are some steps to take:

   1. Check your input parameters and meteorological forcings - are they reasonable for this grid cell? Are they in the correct format?
   2. Check your model time step or snow step - does the problem disappear if you reduce the time step length? (Note: currently VIC cannot support time step lengths < 1 hour)
   3. If your inputs are reasonable, consider setting TFALLBACK to TRUE in the global parameter file. Now, the simulation will continue using the previous time step's temperature value. The number of instances in which the previous step's T value was used will be reported at the end of each grid cell's simulation. In addition, several output variables are available to monitor when these instances occurred: OUT_TFOL_FBFLAG, OUT_TCAN_FBFLAG, OUT_SURFT_FBFLAG, OUT_SOILT_FBFLAG.
   4. If you use the TFALLBACK option, make sure to output the various temperatures simulated by the model (OUT_TFOLIAGE, OUT_TCANOPY, OUT_SURFT, OUT_SOILT) and check that these values look reasonable. In some cases, convergence failures occur long after the model has ventured into unphysical behavior, and using the previous time step's T value simply preserves these unphysical temperatures.
   5. Check if these behaviors are a known issue under investigation. If you do not see the issue listed, please contact us and tell us about the issue.
   
   
9. VIC 4.1.1 gives substantially different results from previous versions of VIC for surface temperature, albedo, and aerodynamic resistance, especially in winter. Why?

   Most of these differences are due to changes in how these variables are reported, rather than differences in the quantities used internally by the model. In all three cases, the values that previous versions of VIC reported did not follow a consistent pattern; in cells with forest canopies, the values would sometimes be representative of the canopy and sometimes representative of the ground surface, depending on whether snow was present in the canopy and other factors. Essentially, the values reported were the last ones used internally.

   In VIC 4.1.1, we have tried to report the "scene" versions of these variables, as follows:

   • Veg tiles containing forest canopy contribute the canopy versions of these quantities (temperature, albedo, and aero. resistance) to the grid cell average.
   • Veg tiles not containing forest canopy contribute the ground surface versions of these quantities to the grid cell average.
   • To see "pure" variables, i.e. either strictly ground surface values or strictly canopy values, we have provided alternate output variables. For example, for albedo, we have:
     • OUT_ALBEDO = "scene" albedo
     • OUT_ALBEDO1 = ground albedo
     • OUT_ALBEDO2 = canopy albedo

   The most noticeable differences with previous versions of VIC occur in winter, when snow is in the canopy. At such times, aerodynamic resistance in the canopy is multiplied by a factor of 10 (by default; see the backwards compatibility page for information on how to change this behavior), and therefore the "scene" aerodynamic resistance will abruptly increase. Similarly, during the spring, when canopy snow is melting, the canopy temperature will be a constant 0 C, which may show up as reduced variability or even a flat line in the grid cell average temperature (depending on percent forest cover). In addition, all three of these quantities may fluctuate between their snow- and non-snow- values as snow falls out of the canopy and is later replenished by subsequent storms. This will be especially evident in aerodynamic resistance and albedo, since both of these quantities have dramatically different values when snow is present or absent in the canopy.

10. I don't see VIC 4.0.7 listed on this web site. Why?

    VIC 4.0.7 is a private, one-off version of VIC that was developed for a special project that Alan Hamlet's group at UW has been working on. It has never been officially released and we do not yet support it here. Some of its features have been incorporated into 4.1.1. If you have questions about VIC 4.0.7, please contact Alan Hamlet.

11. Why does actual evapotranspiration (ET) sometimes exceed potential evapotranspiration (PET)?

    Four of VIC's six types of potential evapotranspiration (PET) estimate PET from vegetative cover. For these calculations, VIC only estimates potential transpiration. However, actual ET contains contributions from both transpiration and evaporation from canopy interception storage. Thus, the total of actual transpiration and canopy evaporation can exceed estimated PET. We are considering adding potential canopy evaporation to the model in the future.