Code Monkey home page Code Monkey logo

vom's Introduction

VOM

The full name of the project is "Coupled Water Balance and Vegetation Optimality Model", in short "VOM". The model predicts vegetation water use based on meteorological information, soils and topography only, without the need for prescribing site-specific vegetation properties or calibration against observed fluxes.

The programme was originally developed by Stan Schymanski at the University of Western Australia (2002-2006), then at the Max-Planck-Institute for Biogeochemistry by Stan Schymanski, Andreas Ostrowski and Steffen Richter (2007-2011), then by Stan Schymanski at ETH Zurich (2011-2017) and since 2017 by Remko Nijzink and Stan Schymanski at the Luxembourg Institute of Science and Technology ( www.list.lu ).

Releases

Latest: DOI

Documentation

The model documentation can be found at: https://vom.readthedocs.io/

An offline version of the documentation can be found in html-format in the folder VOM-docu/build/html/. Two additional pdf files containing equations can be found in VOM-docu: VOM-docu/Equations.pdf and VOM-docu/Watbal3.pdf.

The directory VOM-docu/Fordocu contains automatically generated documenation based on comments in the .f90 files. This one is helpful for understanding the structure of the source code.

Related papers:

Schymanski, S. J., Roderick, M. L., Sivapalan, M., Hutley, L. B. and Beringer, J.: A test of the optimality approach to modelling canopy properties and CO2 uptake by natural vegetation, Plant, Cell & Environment, 30(12), 1586–1598, doi:10.1111/j.1365-3040.2007.01728.x, 2007.

Schymanski, S. J., Roderick, M. L., Sivapalan, M., Hutley, L. B. and Beringer, J.: A canopy-scale test of the optimal water use hypothesis, Plant Cell & Environment, 31, 97–111, doi:10.1111/j.1365-3040.2007.01740.x, 2008a.

Schymanski, S. J., Sivapalan, M., Roderick, M. L., Beringer, J. and Hutley, L. B.: An optimality-based model of the coupled soil moisture and root dynamics, Hydrology and Earth System Sciences, 12(3), 913–932, doi:10.5194/hess-12-913-2008, 2008b.

Schymanski, S. J., Sivapalan, M., Roderick, M. L., Hutley, L. B. and Beringer, J.: An Optimality-Based Model of the Dynamic Feedbacks between Natural Vegetaton and the Water Balance, Water Resources Research, 45, W01412, doi:10.1029/2008WR006841, 2009.

Schymanski, S. J., Roderick, M. L. and Sivapalan, M.: Using an optimality model to understand medium and long-term responses of vegetation water use to elevated atmospheric CO2 concentrations, AoB PLANTS, 7, plv060, doi:10.1093/aobpla/plv060, 2015.

Code description

The initial author of the code and documentation is Stan Schymanski, and initial contributors are Andreas Ostrowski and Steffen Richter.

The main development line (trunk) of the VOM is stored in the following structure:

VOM_Fortran
    /vom-code
        The model code written in Fortran 90 (file extension: f90) 
    /vom-scripts
        Different unix scripts to run the model (file extension: script) for:
            /single_computer
            /cluster 
        You have to adapt the scripts (see documentation: How to run the model, and also the description in script files) 
    /vom-docu
        The model documentation is available in html-code, including some text and pdf files
    /vom-input
        input files needed by the model and example forcing data

vom's People

Contributors

rcnijzink avatar schymans avatar

Stargazers

Yuzhi Zhu avatar Budo Zindovic avatar xiangyi wang avatar  avatar Benjamin Stocker avatar  avatar

Watchers

James Cloos avatar  avatar

vom's Issues

Slow Run Times compared with Output Sample Run, June 2013 (vom_command=1)

Thanks for VOM, from the literature it seems a very promising tool.

Today I downloaded the *master' version, compiled (gfortran, ubuntu 18.04) & 'make check' (passed OK, quick), which used vom_command=2 as the test.

Then ran an sce optimisation using VOM_input data and namelist (i.e. vom_command=1)
This is taking much longer to complete than the run times for the 2013 output sample.

After several hours of restarting and expecting sce_status=1 at least after 90 mins,
no success, so stopped it.
Intervals between runs were 50 minutes, whereas 2013 is approx. 10 mins.

Is there a significant difference between the 2013 model.x file (using scripts) and this 2019 version (run without scripts)?
Any suggestions would be appreciated to at least match the 2013 run times.

All settings used as in the master VOM_input folder (vom_namelist, vom_command=1 etc)

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2013 Run Times:

SHUFFLED COMPLEX EVOLUTION OPTIMISER
Run time: Tue Jun 18 11:07:48 2013
Number of model parameters: 6
Number of optimisable parameters: 6
Maximum number of complexes: 6
Minimum number of runs per complex: 13
Run time: Tue Jun 18 11:07:48 2013
NEW Run time: Tue Jun 18 11:11:55 2013
NEW Run time: Tue Jun 18 11:30:18 2013
NEW Run time: Tue Jun 18 11:47:17 2013
NEW Run time: Tue Jun 18 12:00:42 2013
NEW Run time: Tue Jun 18 12:11:13 2013
NEW Run time: Tue Jun 18 12:19:49 2013
NEW Run time: Tue Jun 18 12:29:04 2013

Check numerical stability for rootdepths close to the total soildepth

For large rooting depths close to the total soil depth (i_cz) the VOM crashes and there are large errors in the waterbalance.

 Start single calculation with parameters...
 Error in water balance [mm]:  -1.0092042767890774E-003 io=   2.2047730265342854E-014 wsold=   2.0667195361495199      wsnew=   2.1370745206789850     
 Program terminated
munmap_chunk(): invalid pointer

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x555b5505612a
#1  0x555b55055ad3
#2  0x7f3704e10f1f
#3  0x7f3704e10e97
#4  0x7f3704e12800
#5  0x7f3704e5b896
#6  0x7f3704e62909
#7  0x7f3704e69ecb
#8  0x555b55061e2a
#9  0x7f3705e17b72
#10  0x7f3704e15040
#11  0x7f3704e15139
#12  0x7f3704df3b9d
#13  0x555b55026929
#14  0xffffffffffffffff
Aborted (core dumped)

Check for NaN and Inf

The VOM produces NaNs with a zr set close to 0, but only when run locally. On the List HPC it runs without a problem. The NCP-values in sce_out.txt are also completely different for local runs.

Quickfix: set zr higher

For the longer term:

  • Add checks for NaN and Inf with divisions
  • Check for type-conversions
  • Force values to be exactly zero below a certain threshold (ie. function tiny, smalles possible number of certain type)

Inconsistent naming of foliage cover-related variables

Here are the relevant lines from modules.f90:

      REAL*8  :: o_cai                  ! Projected cover perennial vegetation (0-1)
      REAL*8  :: pcg_d(3)               ! Projected cover seasonal vegetation (pcg_d(2) is actual value)
      REAL*8  :: lai_lt(3)              ! Local leaf area index trees
      REAL*8  :: lai_lg(3)              ! Local leaf area index grasses

and transpmodel.f90:

      REAL*8 :: Ma_lg(3)      !fraction of absorbed radiation grasses
      REAL*8 :: Ma_lt(3)      !fraction of absorbed radiation trees

Projected cover is usually referred to 1 minus the fraction of bare soil seen from above. This would be equivalent to o_cai*Ma_lt + pcg_d*Ma_lg. Therefore, o_cai and pcg_d should be renamed to crown area index (0-1), and Ma_lg and Ma_lt should be called the 'Local fraction of absorbed radiation...'. This would be more consistent with the fact that pcg_d(1) * Ma_lg(ii) is used to compute jact and rl for grasses.

If the file "sce_status.txt" appears, the model has to be run one more time

Is there a forum to ask questions related to running & using the program?

The manual states:
"If the file "sce_status.txt" appears, the model has to be run one more time to write the results obtained with the optimised parameter set to the disc. This does not take long. Also see below."
See below where?

Ambiguously, does that mean: again run in the terminal $ ./model.x

That produces: $ ./model.x
Restarting SCE from previous run...
ERROR: cannot restart from this state:
SCE already converged

Alternatively, does running the model one more time mean to use switch "vom_command=2" in the vom_namelist and run the optimised parameter set (sce_lastbest.txt) in the pars.txt file?

Thanks for clarification.

Inconsistent use of CAI, LAI and MA

CAI is the crown cover needed for water transport costs, LAI the local leaf area index needed for absorbed radiation and foliage costs, MA is needed only for absorbed radiation.
To compute leaf respiration, we need to use total LAI, i.e. LAI*CAI, not MA, as done e.g. here:

rlg_h(1,:,ii) = ((ca_h(th_) - gammastar) * pcg_d(1) * Ma_lg(ii) * jmaxg_h(:) &

Add quickstart in documentation

It's not really clear in the documentation how to start with the VOM, The vom-scripts folder might be confusing actually.

Correct formulation of Jmax

By going over the 2007-paper, and coding up some of the equations in Jupyter (https://git.list.lu/remko.nijzink/lai_fpar/-/blob/master/notebooks/lai_equations.ipynb), I noticed that the calculation of Jmax in the VOM is dimensionally inconsistent. In the VOM, it is this code:

!     * (Out[310], derived from (3.26)) Temperature dependence of Jmax
      jmaxg_h(:) = (p_E ** ((i_ha * (-25.d0 + tair_h(th_)) * (-273.d0  &
     &           + topt_ + 273.d0 * p_R_ * topt_)) / ((25.d0 + 273.d0  &
     &           * p_R_ * topt_) * (tair_h(th_) + 273.d0 * p_R_        &
     &           * topt_))) * ((-1.d0 + p_E ** (-(i_hd * (-298.d0      &
     &           + topt_)) / (25.d0 + 273.d0 * p_R_ * topt_))) * i_ha  &
     &           + i_hd) * jmax25g_d(:)) / ((-1.d0 + p_E ** ((i_hd     &
     &           * (273.d0 + tair_h(th_) - topt_)) / (tair_h(th_)      &
     &           + 273.d0 * p_R_ * topt_))) * i_ha + i_hd)

In Jupyter, this is:

jmax1

However, the old documentation, says this:

jmax3

Looks like the conversions from air temperature to kelvin have gone wrong with the parenthesis. I put the above also in Jupyter:

jmax2

The differences seem not too big fortunately:

jmax_graph

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.