GithubHelp home page GithubHelp logo

edmodel / ed2 Goto Github PK

View Code? Open in Web Editor NEW
75.0 38.0 110.0 211.21 MB

Ecosystem Demography Model

Shell 3.26% R 25.70% Makefile 0.69% Gnuplot 0.08% Perl 0.24% Fortran 68.32% C 0.33% CSS 0.20% MATLAB 0.99% TeX 0.05% POV-Ray SDL 0.13% Dockerfile 0.01%

ed2's Introduction

Table of Contents

  1. Model Overview
  2. Current version and stable release versions
  3. Repository Contents
  4. Implementation Notes
  5. Further Information
  6. Code Development, Pull Requests, and Commits

The Ecosystem Demography Biosphere Model (ED2) is an integrated terrestrial biosphere model incorporating hydrology, land-surface biophysics, vegetation dynamics, and soil carbon and nitrogen biogeochemistry (Longo et al. 2019;Medvigy et al., 2009). Like its predecessor, ED (Moorcroft et al., 2001), ED2 uses a set of size- and age-structured partial differential equations that track the changing structure and composition of the plant canopy. With the ED2 model, in contrast to conventional biosphere models in which ecosystems with climatological grid cells are represented in a highly aggregated manner, the state of the aboveground ecosystem is described by the density of trees of different sizes and how this varies across horizontal space for a series of plant functional types. This more detailed description of ecosystem composition and structure enables the ED2 model to make realistic projections of both the fast-timescale exchanges of carbon, water and energy between the land and atmosphere, and long-term vegetation dynamics incorporating effects of ecosystem heterogeneity, including disturbance history and recovery.

  • This code available on GitHub is the current version of the model, updated frequently.
  • The latest stable version of the code (ED-2.2) can be found here.
  • For former versions of ED or ED2, check the Moorcroft Lab website.
  • A summary of the main changes between stable releases is available here.

Copies of the ED2 repository should contain the following directories:

  • ED: Contains the ED source code (src) and the directory for compilation (build). For further instructions on how to compile and use the model, we strongly suggest accessing the ED Wiki website: https://github.com/EDmodel/ED2/wiki
  • EDR: Contains the source code (src), build (build), and basic run files (run) for a stripped-down version of the ED2 models radiative transfer scheme.
  • EDTS: Contains the ED model test suite for evaluating the results of changes to the source code under a variety of run conditions.
  • BRAMS: Contains a version of the Brazilian Developments on the Regional Atmospheric Model System (Freitas et al. 2017) that was modified to run coupled biosphere-atmosphere simulations (Knox et al. 2015; Swann et al. 2015). Note: This has not been tested in a while, so the code may need updates to work with the most recent version of ED2.
  • Doc: Contains additional ED2 documentation automatically generated with Doxygen.
  • Ramspost: The BRAMS post-processing program, which generates GrADS files. Note: This has not been tested in a while, so the code may need updates to work with the most recent version of ED2.
  • RAPP: This directory contains the NCEP reanalysis pre-processor, that produces meteorological forcing in the ED-friendly format (HDF5) based on the NCEP/NCAR reanalysis (Kalnay et al 1996). The source code (src) and a build directory are included. The run directory contains the namelist and a shell script to help with the downloading process. A brief instruction can be found in the directory too.Note: This has not been tested in a while, and other users have developed scripts to convert more up-to-date reanalyses.
  • R-utils: A collection of R scripts utilities for model pre- and post-processing (mostly called by R scripts located in ED/Template).

The primary data structure in ED, which can be found in ed_state_vars.F90, is a named, nested array of arrays. Each level of the heirarchy contains many fields of depth one, but the key large scale structure is as follows:

  • grid: The most coarse data in the model. Basically just a simulation book-keeping linking of polygons.
  • polygon: A collection of sites sharing a meteorology.
  • site: A collection of patches sharing a common soil system and ground hydrology.
  • patch: A collection of cohorts sharing a disturbance history and age.
  • cohort: A collection of plants of identical PFT and height.

Note: height and age, being continuous variables, are "binned". "Identical" in this context means sufficiently similar to be placed in the same bin. These bins are dynamically defined, based on the number of classes sought by the user and the similarity along the age and height axes.

  • Most of the existing documentation on how to pre-process, compile, and run the ED2 model is available in our Wiki.
  • For the technical description of the various ED2 model features, we suggest looking at this reference list (Tip: do not skip the Supporting Information of these papers, they contain relevant details).
  • For a partial list of studies that have used ED or ED2, check here.

If you plan to develop the code, please refer to the Wiki entries on code organization and design philosophy, to ensure your code developments are consistent with the existing model. Also, make sure that the code is thoroughly tested, and successfully passes the internal GitHub tests.

We strongly encourage that code developments are properly documented. Please refer to the Doxygen instructions, and especially the Doxygen and Git commits section, so additional documentation can be automatically generated from the source code comments.

ed2's People

Contributors

aariq avatar apourmok avatar ashiklom avatar badgley avatar crollinson avatar danielnscott avatar dmedvigy avatar gklarenberg avatar istfer avatar levinelab avatar lo-hatch avatar manfredo89 avatar mdietze avatar mpaiao avatar mrjohnston avatar rgknox avatar robkooper avatar xiangtaoxu avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ed2's Issues

Why is specific humidity limited at 0.032?

I am wondering what is the reason for setting maximum specific humidity to 0.032. I understand that the dewpoint at 32°C and 1000hPa corresponds to .032. However in my data set I have cases in which I have a specific humidity higher than .032 but my relative humidity is less than 100%. Perhaps there is some physics law that I am not aware of so I apologize in advance this sounds like a silly question.what is the reason for using a "static" specific humidity at these conditions?

These are some examples in my data set, I have used David LeBauer R script to calculate relative humidity.

temp[y]
[1] 34.01617 33.94131 34.24038 34.61071 35.38662 34.64257 34.05575 34.26895 35.48477 35.56072
[11] 32.82665 33.30193 36.37802 34.32531 35.53552 34.27352 35.56439 36.65029 34.24539
pres[y]
[1] 958.2904 961.2945 966.2562 958.0849 961.8770 959.6063 953.5177 955.0603 956.4476 953.5868
[11] 903.1379 903.8415 950.6209 950.8947 950.8907 953.0804 950.4606 946.3468 947.5901
qair[y]
[1] 0.03300236 0.03323020 0.03360319 0.03318560 0.03589034 0.03456816 0.03369993 0.03337700
[9] 0.03615537 0.03616529 0.03308699 0.03325040 0.03340801 0.03428431 0.03527325 0.03384901
[17] 0.03507772
qair2rh(qair[y],temp[y],pres[y])
[1] 0.9350099 0.9482467 0.9476671 0.9092553 0.9441408 0.9461811 0.9475259 0.9290256 0.9404769
[10] 0.9339865 0.9443846 0.9246411 0.8235791 0.9466251 0.9101225 0.9397065 0.9033312 0.8702408

do I need permission to push some changes?

I am trying to push some changes, only a couple of files inside RAPP, but I get this message.

remote: Permission to EDmodel/ED2.git denied to fabeuw.
fatal: unable to access 'https://github.com/EDmodel/ED2.git/': The requested URL returned error: 403

I am not sure if I need to be given permission or if I push these to my fork and then open a pull request. Git status tells me I am on the branch master

carya@pecan64:~/edf/RAPP/build/bin$ git status
On branch master

Transpiration too high

Hi Everyone,

I'm trying to do a bare-ground spinup at 6 sites and am encountering a problem where the soil moisture gets extremely dry (as dry as it can physically be) due to transpiration after some period of time (10-50 years). Has anybody else been having this or a similar problem? Or transpiration just being extremely high?

Mean June transpiration at Harvard Forest 10 years into a bare ground spin is 3.7e-5 kg/m2/s and I'm losing 1e-6 to 4e-6 kg/m2/s from the different soil layers due to transpiration.

Does anybody have any suggestions on where to look to try and crank transpiration down? I've tried tweaking just about every photosynthesis or leaf-area related PFT parameter and ED2IN setting imaginable, so I think there might be a bug that's not closing enough stomata or letting photosynthesis saturate, but I'm not sure. If it helps, my base PFT parameterization file (which I've been tweaking) can be found here: https://github.com/crollinson/ED_Processing/blob/master/PalEON_Phase1a.v2.xml

If anybody has any thoughts, I'd really appreciate it!

Turnover Time Defaults

Check out the code below from ed_params.f90. The slow soil carbon decay rate is really high, and it seems plausible that people are running the model without nitrogen limitation OR a knowledge that their runs have nutty decay rates. Maybe it's time to change this, or at least make some note of it in the ED2IN?

   !---------------------------------------------------------------------------------------!
   ! MLO.  After talking to Paul, it seems the decay rate for the slow carbon pool is      !
   !       artificially high for when nitrogen limitation is turned on.  If it is turned   !
   !       off, however, then the slow carbon will disappear very quickly.  I don't want   !
   !       to mess other people's results, so I will change the rate only when             !
   !       decomp_scheme is 2, and only when nitrogen limitation is off.  I think this     !
   !       should be applied to all schemes, but I will let the users of these schemes to  !
   !       decide.                                                                         !
   !---------------------------------------------------------------------------------------!
   select case (decomp_scheme)
   case (0,1)
      decay_rate_fsc  =  11.0 / yr_day    ! former K2
      decay_rate_stsc =   4.5 / yr_day    ! former K1
      decay_rate_ssc  = 100.2 / yr_day    ! former K3
   case (2)
      decay_rate_fsc  =  11.0 / yr_day    ! former K2
      decay_rate_stsc =   4.5 / yr_day    ! former K1
      select case (n_decomp_lim)
      case (0)
         decay_rate_ssc  =   0.2 / yr_day ! former K3
      case (1)
         decay_rate_ssc  = 100.2 / yr_day ! former K3
      end select
   end select
   !---------------------------------------------------------------------------------------!

Marcos' solution seems pragmatic, but I agree that the SSC rate should be changed across all conditions. Not changing it seems more likely to cause confusion/ bad results than doing so.

Can't create rapp_1.0 executable

When I run the make file it seems to build all dependencies and compile everything, but in the end it doesn't create rapp_1.0 but only rapp_1.0.a

cp -f /home/carya/edf/RAPP/src/ncep/ncep_loadvars.F90 ncep_loadvars.F90
gfortran -DUSE_NCDF=1 -DPC_LINUX1 -DUSE_HDF5=1 -O3 -static -ffree-line-length-none -I/usr/include -c ncep_loadvars.F90
rm -f ncep_loadvars.F90
ar rs /home/carya/edf/RAPP/build/rapp_1.0.a an_header.o charutils.o dateutils.o dealloc_driver.o ed_metd_header.o fatal_error.o great_circle.o hdf5_coms.o hdf5_utils.o interp_driver.o load_namelist.o mod_grid.o mod_interp.o mod_ioopts.o mod_maxdims.o mod_model.o mod_namelist.o mod_ncdf_globio.o mod_ncep.o mod_netcdf.o mod_time.o numutils.o ncepcio.o ncep_alloc.o ncep_coordinates.o ncep_fill_infotable.o ncep_loadvars.o ncep_output.o rain_downscale.o rapp_driver.o rapp_opspec.o rconstants.o rsys.o space_interp.o therm_lib.o time_interp.o utils_f.o

o /home/carya/edf/RAPP/build/rapp_1.0 rapp_main.o /home/carya/edf/RAPP/build/rapp_1.0.a -lz -lhdf5_fortran -lhdf5 -lhdf5_hl
make[1]: o: Command not found
make[1]: [/home/carya/edf/RAPP/build/rapp_1.0] Error 127 (ignored)

Finished building === /home/carya/edf/RAPP/build/rapp_1.0

make[1]: Leaving directory `/home/carya/edf/RAPP/build/bin'

I have tried to set in include the LOADER variable to gfortran but I get another set of errors

gfortran -o /home/carya/edf/RAPP/build/rapp_1.0 rapp_main.o /home/carya/edf/RAPP/build/rapp_1.0.a -lz -lhdf5_fortran -lhdf5 -lhdf5_hl
/home/carya/edf/RAPP/build/rapp_1.0.a(ncep_fill_infotable.o): In function ncep_load_var_table_': ncep_fill_infotable.F90:(.text+0x113): undefined reference to__netcdf_MOD_nf90_inquire_variable'
/home/carya/edf/RAPP/build/rapp_1.0.a(ncep_fill_infotable.o): In function ncep_fill_infotable_': ncep_fill_infotable.F90:(.text+0x1395): undefined reference to__netcdf_MOD_nf90_open'
ncep_fill_infotable.F90:(.text+0x13c3): undefined reference to __netcdf_MOD_nf90_inquire' ncep_fill_infotable.F90:(.text+0x1d22): undefined reference to__netcdf_MOD_nf90_close'
/home/carya/edf/RAPP/build/rapp_1.0.a(ncep_loadvars.o): In function loadshort_': ncep_loadvars.F90:(.text+0xaf): undefined reference to__netcdf_MOD_nf90_open'
ncep_loadvars.F90:(.text+0x17e): undefined reference to __netcdf_MOD_nf90_close' /home/carya/edf/RAPP/build/rapp_1.0.a(mod_ncdf_globio.o): In function__mod_ncdf_globio_MOD_ncdf_load_err

Cannot open met driver input file

---> File: ed_met_driver.f90
---> Subroutine: read_met_drivers_init
---> Reason: Cannot open met driver input file /mnt/met_data/h5/WIND_2000FEB.h5!

Given that the h5 files exists and that I am able to open it with HDFview, what could cause this error message?

cbr_now scheme

In older version of ED, cbr_now = cb/cb_max

ED2 Master has the following scheme:
cbr_now = stress + (cbr_light - stress)_(cbr_moist - stress) / ((ddmort)_cbr_lightmax + (1-ddmort)*cbr_moistmax - stress)

Can someone explain the rationale for how this was developed?

It seems to me like a form more in line with what is described in the ED2IN and previous versions would be:
cbr_now = cb/(ddmort_cbr_lightmax + (1-ddmort)_cbr_moistmax)

LULC in ED2

Has anybody recently run ED with land use/land change turned on (IANTH_DISTURB=1)?

It doesn't seem to be able to read the files we currently have and I'm trying to figure out if we need to change the code or the inputs.

Error opening site file ...

Hello,

I noticed that with the current as of writing version of ED2, or at least I only noticed it with it, that when I run the ED2 with the pss and css files, it gives initially a warning that it had a problem opening the site file at the location which is exactly the location and the name of the site file and when listing the files with the correct prefix shows the site file in question.

I am curious have others noticed this problem and how harmful an issue it is?

-- Toni

RAPP: "No rule to make target `hdf5.mod', needed by `hdf5_coms.o'. Stop."

When I try to make the RAPP executable (Mac OS X), I get the above error.

I checked my path in the include.mk file:
"HDF5_INCS=-I/usr/local/hdf5/include"

and this is indeed where hdf5.mod sits. I can't figure out what the issue is.
I (successfully) installed HDF5 and NetCDF earlier this week, and had to "sudo make" to get it to install, but that does not solve the problem here.
I just (today) got the latest ED / RAPP code from github.

Any ideas?
Thanks - Geraldine

Multiple Badness in Multiple time-stamps in instantaneous output

The ED2IN text describing how to write multiple time-stamps per file is so wrong... and... then when I figure it out, it so doesn't work.

We supposedly have functionality that allows multiple time instances of model output per instantaneous output files. I cannot get it working for my runs. The text in the ED2IN says that OUTFAST AND OUTSTATE have a time unit, but it doesn't, it should be an integer stating a number of counts per file. It also says that FRQFAST is the time between files, but it totally isn't, it acts as the time between time-stamps.

Can anyone re-produce this problem or get it to work?

For instance, if I want hourly instantaneous output sent to daily files, this is what one would interperate from the ED2IN descriptions:

IFOUTPUT = 3
UNITFAST = 0
OUTFAST = 24
FRQFAST = 86400

it does not work, as you can see I am left with a single time in the file:

h5dump -d FMEAN_CAN_CO2_PY oxi_v4_pi_test-I-2001-12-02-000000-g01.h5
HDF5 "oxi_v4_pi_test-I-2001-12-02-000000-g01.h5" {
DATASET "FMEAN_CAN_CO2_PY" {
DATATYPE H5T_IEEE_F32LE
DATASPACE SIMPLE { ( 1 ) / ( 1 ) }
DATA {
(0): 320.785
}
}
}

So I tried this,

IFOUTPUT = 3
UNITFAST = 0
OUTFAST = -1
FRQFAST = 3600

and now it allocates 24 time-stamps, but only fills the first one....

h5dump -d FMEAN_CAN_CO2_PY oxi_v4_pi_test-I-2001-12-02-000000-g01.h5
HDF5 "oxi_v4_pi_test-I-2001-12-02-000000-g01.h5" {
DATASET "FMEAN_CAN_CO2_PY" {
DATATYPE H5T_IEEE_F32LE
DATASPACE SIMPLE { ( 24, 1 ) / ( 24, 1 ) }
DATA {
(0,0): 320.374,
(1,0): 0,
(2,0): 0,
(3,0): 0,
(4,0): 0,
(5,0): 0,
(6,0): 0,
(7,0): 0,
(8,0): 0,
(9,0): 0,
(10,0): 0,
(11,0): 0,
(12,0): 0,
(13,0): 0,
(14,0): 0,
(15,0): 0,
(16,0): 0,
(17,0): 0,
(18,0): 0,
(19,0): 0,
(20,0): 0,
(21,0): 0,
(22,0): 0,
(23,0): 0
}
}
}

Canopy Air CO2

In long runs, I occasionally encounter an issue where there's a rejected step problem and the Canopy Air CO2 is off-track. I encountered this problem pre-snow fixes, but it's back in more recent runs.

STEPSIZE UNDERFLOW IN EULER_INT

  • LONGITUDE: -94.580002
  • LATITUDE: 46.279999
  • PATCH INFO:
    • NUMBER: 12
    • AGE: 3.4167E+00
    • DIST_TYPE: 3
  • MINSTEP: T
  • STUCK: F
  • ERRMAX: 1.0000E+01
  • X: 8.2916E+02
  • H: 6.8684E-08
  • OLDH: 1.3571E-07
  • NEWH: 6.8684E-08

+ SAFETY: 9.0000E-01

Likely to be a rejected step problem.

+ Canopy air CO2 is off-track...

CAN_THETA: 2.9332E+02
CAN_SHV: 1.3859E-02
CAN_RHV: 8.8968E-01
CAN_TEMP: 2.9093E+02
CAN_RHOS: 1.1594E+00
CAN_CO2: 3.0000E+01
CAN_DEPTH: 5.0000E+00
CAN_PRSS: 9.7173E+04
D(CAN_TEMP )/Dt: 0.0000E+00
D(CAN_SHV )/Dt: -6.1485E-06

D(CAN_CO2 )/Dt: -1.2232E-01

Can't find mpif.h and many other header files.

I am trying to compile the ED with mpich and hdf5 using the GFORTRAN include file. I am new to these types of the model. By the way when i try ./instal.sh the error is compiler can not find the mpif.h and some other include files residing in /ED/src/mpi/ed_empass_init.f90 and /ED/utils/utils_c.c . Do you have any idea what could be the possible reason for that?

Thanks,
hamid

Running ED2 as a MPI ensemble

Hello,

This is actually something that was solved in the earlier version of ED2, but this version has an issue with. So if I run ED2 in DART as an MPI ensemble, where the program is executed by different ensemble members, the ensemble crashes because ED2 automatically tries to run as a MPI program inside another MPI program.

This was solved in the previous version by doing some adjustments to it and then running it with -s after the executable and I was wondering can the same modification be done for the Github version.

-- Ton

Error compiling RAPP, different character lengths

I can't see to compile mod_ncep.f90, neither via make neither manually, in both cases I get the same error. I checked online and some mention to pad the string length by adding extra character, I tried that but with no result. Does anybody have an idea what might be causing this?

mpif90 -O3 -ffree-line-length-none -fno-whole-file -I/usr/include -c mod_ncep.f90
OR
carya@pecan64:~/edf/RAPP/build/bin$ gfortran -o mod_ncep -I/usr/include mod_ncep.f90 -L/usr/lib64 -lnetcdff -lnetcdf -lhdf5 -lm -lhdf5_fortran -lhdf5 -lhdf5_hl -lz
mod_ncep.f90:61.25:

                    , 'pres'             & ! Pressure                      
                     1

Error: Different CHARACTER lengths (3/4) in array constructor at (1)
mod_ncep.f90:81.54:

            (/ 'air.sig995/air.sig995'           , 'pres.sfc/pres.sfc'     
                                                  1

Error: Different CHARACTER lengths (21/17) in array constructor at (1)
mod_ncep.f90:108.25:

                    , 'pres'             & ! Pressure                      
                     1

Error: Different CHARACTER lengths (3/4) in array constructor at (1)
mod_ncep.f90:118.25:

                    , 'nbdsf'            & ! Near-IR beam radiation        
                     1

Error: Different CHARACTER lengths (3/5) in array constructor at (1)
mod_ncep.f90:126.25:

                    , 'prate'           /) ! Precipitation rate            
                     1

Error: Different CHARACTER lengths (3/5) in array constructor at (1)

DATASET_README.1ST file missing in RAPP

just a minor thing but the DATASET_README.1ST file mentioned in the RAPP wiki is missing, the same file is also mentioned in the RAPP_IN instructions. Has this file been deleted or has it changed name?

sapwood ratio ref

If anyone knows the reference for our parametrization of sapwood_ratio(1:17) = 3900 (see ed_params.f90), please chime in and lets get it in the code.

Unit consistency when calculating qsw suggests that sapwood_ratio is [m2 leaf / kg sapwood]. the definition in pft_coms for sapwood_ratio is a little vague, it says "area ratio"

qsw: [kg sapwood] / [kg leaf]
SLA: [m2 leaf] / [kg leaf]
sapwood_ratio: [m2 leaf]/[kg sapwood] ??

Spatially Explicit ED for Agroforestry

Hi all,
My name is Kevin Wolz, and I'm a PhD student at UIUC. I've worked sporadically with a few of you in the past (hey there @mdietze, @ryankelly-uiuc, @serbinsh, @dlebauer), but I'm pretty new to ED and this group.

I come to you from the world of agroforestry. Specifically, my work focuses on mixed-species agroforestry systems, where multiple plant functional types are integrated into a a single system (e.g. canopy trees, shrubs, and ground cover). I utilize several field sites here at Illinois to understand how the transition from corn/soy to food-producing woody systems will effect biogeochemical processes. However, since there are an infinite number of possible agroforestry designs, crops, orientations, etc., field sites are not enough. Models are critical.

A really great review of modeling in mixed-species ag systems (including agroforesty systems) can be found here: http://link.springer.com/article/10.1051%2Fagro%3A2007057. Honestly, this article is quite depressing. This article concludes with: "Today, it is barely feasible to simulate multi-species systems and, due to the absence of efficient models, it is difficult to understand the effects of the different factors that interact within those systems." As developers of the preeminent model that does exactly this, I imagine you would take serious offense to this conclusion.

The truth is that most of the agroforesty models included in that review, as well as most others, have been all but abandoned because they were either overly simplistic (i.e just dealt with competition for light) or were created for very specific systems. The state of the modeling science in that community is pathetic, at best. Most attempts to model agroforesrty systems have started from the agronomy side of things and then tried to layer in ecological complexity. This is not only difficult, but, I think, a complete waste of time since ED already has most of that ecological complexity!

WE NEED ED!

I think ED can become a major asset for the agroforestry community, and my vision is to adapt ED for use in these types of systems. While there are many minor tweaks that would help enable ED for use in agroforestry, there is one critical need: making ED spatially explicit. What I mean by this is that individuals in each PFT need to be arranged in a specific spatial pattern in the landscape. To make this a bit clearer (I hope), the image below shows example systems that we are studying here at Illinois. They represent the "typical" agroforestry system: parallel rows of one or more woody species separated by an "alley" that can be used for row crops, grazing, etc.

ed_explanation

So, I'm throwing this out there to this community because, while I am extremely excited about this, I neither have the time nor the skill set to make this happen. I honestly don't even know how monstrous the task I'm proposing is. Is this the scope of a late night's work? A master's thesis? An entire career? Any and all ideas, suggestions, condemnations, or anything else would be deeply appreciated. All of us working in this field are just spinning our wheels on the modeling side of things. I just wanted to break down the wall and open communication with those of you on the other side...

Looking forward to discussing and collaborating!

soil table "soil()%" is filled as if grid dependent - its not

in ed_params.f90:
subroutine init_soil_coms:

the table soil(nslcon)%stuff is poplulated inside a loop that iterates grids. The loop tests to see if isoilflg(ifm)==2 (where the user sets sand, silt and clay fractions). However, the table is not indexed by grid, so the last isoilflg(ifm) will control the destiny of the table.

Two potential fixes:

  1. changes isoilflg to a single integer not a vector the size of the number of grids (ie forcing all grids to the same soil definition schema).
  2. make soil(1:nslcon) a function of the grid too soil(ifm,1:nslcon)

ED2 crashes at the change of the year

Just letting people know that ED2, at least for me, crashes when switching between years. It does not seem to be related to the bug fix pushed through latelt and I am currently trying to isolate the issue. The error message is

  • Simulating: 12/31/2000 00:00:00 UTC
    [geo:50870] *** Process received signal ***
    [geo:50870] Signal: Segmentation fault (11)
    [geo:50870] Signal code: Address not mapped (1)
    [geo:50870] Failing at address: 0x11a9e15c0
    [geo:50870] [ 0] /lib64/libpthread.so.0(+0xf710) [0x7f1a1e6fc710]
    [geo:50870] [ 1] ./ed_2.1-opt(ed_state_vars_MOD_copy_sitetype_mask_qmean+0x1a8) [0x52bfa8]
    [geo:50870] [ 2] ./ed_2.1-opt(_ed_state_vars_MOD_copy_sitetype_mask+0x685) [0x54bd15]
    [geo:50870] [ 3] ./ed_2.1-opt(disturbance_utils_MOD_apply_disturbances+0x2691) [0x7b1721]
    [geo:50870] [ 4] ./ed_2.1-opt(vegetation_dynamics
    +0x2d3) [0x7316f3]
    [geo:50870] [ 5] ./ed_2.1-opt(ed_model
    +0xd88) [0x47c078]
    [geo:50870] [ 6] ./ed_2.1-opt(ed_driver
    +0x4f5) [0x426a55]
    [geo:50870] [ 7] ./ed_2.1-opt(MAIN
    +0x9bc) [0x42442c]
    [geo:50870] [ 8] ./ed_2.1-opt(main+0x2a) [0x7e064a]
    [geo:50870] [ 9] /lib64/libc.so.6(__libc_start_main+0xfd) [0x7f1a1e377d5d]
    [geo:50870] [10] ./ed_2.1-opt() [0x4239a9]
    [geo:50870] *** End of error message ***
    Segmentation fault (core dumped)

Variables in tower analysis files removed

Tower output files, suffix -T-, used to have bunch of AVG_* variables which calculated outputs corresponding to the tower data, have been removed for the current git version.

This is causing issues for our PEcAn workflow, which tries to read those outputs, so we wanted to check if there was a reason these variables were removed from ED2.

Tips for zoobukhov8 convergence?

One of my sites is having trouble with zoobukhov8 convergence. I've tried a number of things, including cranking down the time step, but can't get it to go through. I'm running with ISFCLYRM = 4, but have tried the others that don't require starting from an initial state again. (I'm trying to avoid having to start over and lose the 500 years I've already run).

Here's what the print statement says when it crashes:


Zeta finding didn't converge!!!
I gave up, after 60 iterations...

Input values.

rib [ ---] = 0.0000
ribuse [ ---] = 0.0000
zstar [ m] = 4.6240
rough [ m] = 5.0528
zoz0m [ ---] = 0.9152
lnzoz0m [ ---] = -0.0887
zoz0h [ ---] = 0.9152
lnzoz0h [ ---] = -0.0887
stable [ T|F] = F

Last iteration outcome (zoobukhov8 values).
zetaa [ ---] = 0.0001
zetaz [ ---] = -0.0000
fun [ ---] = -0.0000
fm [ ---] = -0.0887
fh [ ---] = -0.0887
funa [ ---] = -0.0000
funz [ ---] = 0.0001
deriv [ ---] = -1.0000
toler [ ---] = 1.1921E-06
error [ ---] = 4.7418E+01
zoobukhov8 [ ---] = 0.0001


sfmakedepend.pl

I'm new to ED and am trying to install the main ED2 branch on a machine running redhat linux. I'm
having the problem that the sfmakedepend.pl script is hanging and times out. It's not generating any
errors. Has anyone encountered this? Any thoughts appreciated.

Thanks,
Matt

Error compiling with gfortran

Trying to get the latest version of ED to compile on a Ubuntu VM results in the following error:

mpif90 -c -O3 -ffree-line-length-none  -fno-whole-file  -I../../src/include -I/usr/include   -DRAMS_MPI disturbance.f90
disturbance.f90:787.41:

                                    if ( include_pft(ipft) == cpatch%pft(1) ) t
                                         1
Error: Operands of comparison operator '==' at (1) are LOGICAL(4)/INTEGER(4)

wind speed (vels), ugrd, vgrd, possible conversion error RAPP

My run stops because wind speed turns out to be "infinity". The variable in lapse.f90 is cpoly%met(isi)%vels but I can't find where in the code wind speed is calculated. I checked my data and both vgrd and ugrd have values such as -3.45436E30. And the NCEP original values look fine. So perhaps this is what's causing the infinity value. Maybe something in the NCEP conversion in RAPP went wrong? @mpaiao do you have an idea what might be causing this?

EDIT: vgrd has the same problem.

Uninitialized variable Clean-Up

While helping debug the SMP issues ( #30 ), I've discovered there are currently 5 cases of uninitialized variables in the mainline branch and would appreciate some help tracking them down so we can document in the code that this is okay or fix them (preferable):

  1. rk4_misc.f90: In function 'adjust_sfcw_properties':
    rk4_misc.f90:1565: warning: 'depth_available' may be used uninitialized in this function

  2. ed_state_vars.f90: In function 'copy_sitetype_mask':
    ed_state_vars.f90:8795: warning: 'i' may be used uninitialized in this function

  3. ed_read_ed21_history.F90: In function 'read_ed21_history_file':
    ed_read_ed21_history.F90:447: warning: 'si_index' may be used uninitialized in this function

  4. heun_driver.f90: In function 'heun_stepper':
    heun_driver.f90:807: warning: 'combh' may be used uninitialized in this function

  5. events.f90: In function 'event_irrigate':
    events.f90:649: warning: 'soil_temp' may be used uninitialized in this function

  6. I have tracked down and solved the first one. (see #30 )

  7. This stems from a change by @mpaiao on I think 14 November 2012 (commit 37188de). Marcos, I can't quite figure out what's going on here (probably just me not understanding the syntax). If what I think is happening is right, this actually isn't a problem, but it'd be great if you could double check.

  8. @rgknox I think this one might come in from one of your commits (circa June 2012) based a quick scan of the history on that file. Could you maybe take a glance to see if you can figure out what's going on?

I haven't looked into 4 or 5 yet, but if somebody knows who added the irrigation or worked on the heun stepper, it'd be great if they could help fill in the gaps.

Issue trying to install bleeding edge ED2 on Linux server

./install.sh
rules.mk:551: dependency.mk: No such file or directory
make: ***No rule to make target 'dependency.mk'. Stop.

I don't have this issue with older versions, including r82 that you can install using the PEcAn instructions. Has anyone else had this issue before?

System specifics:
Sci Linux (RHEL/CentOS 6.5)
Using gfortran compiler, openmpi, etc, etc...standard stuff

Decomposition rate of coarse woody litter in ED

Hi everyone,
My name is Paulo Araujo Filho, I'm working with the decomposition rate of coarse woody litter in ED.

It is commonly understood what the rate decay of the woody coarse litter, stems and branches, are influenced by wood density, moisture content and temperature. Whereas the moisture content inside of the wood is influence by wood density.

Could anyone recommend or know of research that has sought to understand mass and energy flux in and out of coarse dead wood? Or, does anyone know of such modules that have already been built or tested?

It is my understanding that no such module exists in ED right now (but maybe not?), and I am excited at the possibility of runing some experiments with this functionality.

Thanks!

Do not add your *.mod files to Git repository

I am not sure if anyone else is running to the same problem or not but *.mod files in .build/bin should not be added to git repository since they will be created during compilation. Adding them causes issue that every time you want to switch between branches or commit or pull upstream, you need to remove them manually.

Growth resp out of tomorrow's GPP?

Does anyone know why growth respiration calculated as a tax on today's daily_C_gain and then taken from tomorrow's daily_C_gain? In case folks don't remember, daily_C_gain is a rescaling of today_gpp - today_leaf_resp - today_root_resp. This is something I've wondered about for a while...

Supporting code snippets, from growth_balive.f90:
In dbalive_dt:

                  !------------------------------------------------------------------------!
                  !     Compute maintenance costs using actual pools.                      !
                  !------------------------------------------------------------------------!
                  call plant_maintenance(cpatch,ico,cpatch%broot(ico),cpatch%bleaf(ico)    &
                                        ,tfact,daily_C_gain,csite%avg_daily_temp(ipa))

 [...some_stuff...]

                  cpatch%storage_respiration(ico) = cpatch%bstorage(ico)                   &
                                                  * storage_turnover_rate(ipft)            &
                                                  * tfact * temp_dep

                  cpatch%bstorage(ico) = cpatch%bstorage(ico)                              &
                                         - cpatch%storage_respiration(ico)

 [...more_stuff...]
                  !------------------------------------------------------------------------!
                  !      Calculate actual, potential and maximum carbon balances.          !
                  !------------------------------------------------------------------------!
                  call plant_carbon_balances(cpatch,ipa,ico,daily_C_gain,carbon_balance    &
                                            ,carbon_balance_pot,carbon_balance_lightmax    &
                                            ,carbon_balance_moistmax)
                  !------------------------------------------------------------------------!



                  !------------------------------------------------------------------------!
                  !      Compute respiration rates for coming day [kgC/plant/day].         !
                  !------------------------------------------------------------------------!
                  cpatch%growth_respiration(ico) = max(0.0, daily_C_gain                   &
                                                          * growth_resp_factor(ipft))
                  !------------------------------------------------------------------------!

                  !------------------------------------------------------------------------!
                  !     Find the "virtual" leaf respiration.                               !
                  !------------------------------------------------------------------------!
                  cpatch%vleaf_respiration(ico) = (1.0-cpoly%green_leaf_factor(ipft,isi))  &
                                                * salloci * cpatch%balive(ico)             &
                                                * storage_turnover_rate(ipft)              &
                                                * tfact * temp_dep
                  !------------------------------------------------------------------------!


                  !------------------------------------------------------------------------!
                  !      Allocate plant carbon balance to balive and bstorage.             !
                  !------------------------------------------------------------------------!
                  balive_in = cpatch%balive(ico)

                  if(is_grass(ipft).and. igrass==1) then
                      call alloc_plant_c_balance_grass(csite,ipa,ico,salloc,salloci        &
                                                ,carbon_balance,nitrogen_uptake            &
                                                ,cpoly%green_leaf_factor(ipft,isi))
                      call sort_cohorts(cpatch)
                  else
                      call alloc_plant_c_balance(csite,ipa,ico,salloc,salloci              &
                                                ,carbon_balance,nitrogen_uptake            &
                                                ,cpoly%green_leaf_factor(ipft,isi))
                  end if
                  !------------------------------------------------------------------------!

plant_carbon_balances:

      !------------------------------------------------------------------------------------!
      !       Calculate actual daily carbon balance: kgC/plant/day.                        !
      !------------------------------------------------------------------------------------!
      carbon_balance = daily_C_gain - cpatch%growth_respiration(ico)                       &
                                    - cpatch%vleaf_respiration(ico)
      !------------------------------------------------------------------------------------!

Met driver header file and netcdf files

Hello,
I was wondering if anybody could explain how to create a header file. I have look at several templates but I am still confused.

Is it possible for ED to read directly the Sheffield met files in .nc format?

Europe ED working groups

Does someone know who in Europe is working with ED? I am a PhD student looking for a collaboration to develop a project on seed dispersal and disturbance, but nobody in my current department has any modeling expertise with ED.

I have met a group in Ghent that uses ED, anybody else?

Problem with compiling due to radiate_driver.f90

I pulled the latest main line changes in to my local branch and when I try to compile the code, I keep getting the error message below (I already tried ./install.sh clean) which is related to radiate_driver.f90 file, any thoughts what is causing it?

Error: Expecting END IF statement at (1)
radiate_driver.f90:1067.3:

end subroutine sfcrad_ed
1
Error: Expecting END IF statement at (1)
radiate_driver.f90:1080.4:

real function ed_zen(plon,plat,when)
1
Error: 'real' at (1) is not a variable
radiate_driver.f90:1081.55:

use ed_misc_coms , only : simtime ! ! structure
1
Error: Unexpected USE statement at (1)
radiate_driver.f90:1085.56:

                       , tiny_num8    ! ! intent(in)
                                                    1

Error: Unexpected USE statement at (1)
radiate_driver.f90:1086.16:

implicit none
1
Error: Unexpected IMPLICIT NONE statement at (1)
radiate_driver.f90:1088.36:

real(kind=4) , intent(in) :: plon
1
Error: Unexpected data declaration statement at (1)
radiate_driver.f90:1089.36:

real(kind=4) , intent(in) :: plat
1
Error: Unexpected data declaration statement at (1)
radiate_driver.f90:1090.16:

type(simtime), intent(in) :: when
1
Error: Derived type 'simtime' at (1) is being used before it is defined
radiate_driver.f90:1092.68:

integer :: doy ! Day of year ("Julian" day)
1
Error: Unexpected data declaration statement at (1)
radiate_driver.f90:1093.53:

real(kind=8) :: declin ! Declination
1
Error: Unexpected data declaration statement at (1)
radiate_driver.f90:1094.61:

real(kind=8) :: sdec ! Sine of declination
1
Error: Unexpected data declaration statement at (1)
radiate_driver.f90:1095.63:

real(kind=8) :: cdec ! Cosine of declination
1
Error: Unexpected data declaration statement at (1)
radiate_driver.f90:1096.54:

real(kind=8) :: dayhr ! Hour of day
1
Error: Unexpected data declaration statement at (1)
radiate_driver.f90:1097.61:

real(kind=8) :: radlat ! Latitude in radians
1
Error: Unexpected data declaration statement at (1)
radiate_driver.f90:1098.61:

real(kind=8) :: clat ! Cosine of latitude
1
Error: Unexpected data declaration statement at (1)
radiate_driver.f90:1099.58:

real(kind=8) :: slat ! Sine of latitude
1
Error: Unexpected data declaration statement at (1)
radiate_driver.f90:1100.64:

real(kind=8) :: dayhrr ! Hour of day in radians
1
Error: Unexpected data declaration statement at (1)
radiate_driver.f90:1101.52:

real(kind=8) :: hrangl ! Hour angle
1
Error: Unexpected data declaration statement at (1)
radiate_driver.f90:1103.85:

nd=8), parameter :: capri = -2.344d1 ! Tropic of Capricornium latitude
1
Error: Unexpected data declaration statement at (1)
radiate_driver.f90:1104.92:

parameter :: ndaysnl = 3.65d2 ! Number of days of year (no leap years)
1
Error: Unexpected data declaration statement at (1)
radiate_driver.f90:1105.89:

), parameter :: ndayslp = 3.66d2 ! Number of days of year (leap years)
1
Error: Unexpected data declaration statement at (1)
radiate_driver.f90:1106.87:

, parameter :: shsummer = -10 ! DoY of Southern Hemisphere summer
1
Error: Unexpected data declaration statement at (1)
radiate_driver.f90:1108.85:

 , external    :: julday  ! Function to find day of year ("Julian" day)
                                                                       1                                                                                                   

Error: Unexpected data declaration statement at (1)
radiate_driver.f90:1109.88:

, external :: isleap ! Function to determine whether the year is leap
1
Error: Unexpected data declaration statement at (1)
Fatal Error: Error count reached limit of 25.
make[1]: *** [radiate_driver.o] Error 1
make[1]: Leaving directory `/usr2/postdoc/apourmok/ED2-1/ED/build/bin'
make: *** [all] Error 2

Download subest of NCEP reanalysis via batch script

The current RAPP code downloads every variable at the global scale, however some people might only need a subset of it. The NOAA ESRL website has the option of downloading a subset of any variable via query, for example to download air pressure
www.esrl.noaa.gov/psd/cgi-bin/GrADS.pl?dataset=NCEP+Reanalysis+Pressurde+Level&DB_did=2&file=%2FDatasets%2Fncep.reanalysis%2Fpressure%2Fair.1948.nc+air.%25y4.nc+98300&variable=air&DB_vid=13&DB_tid=45857&units=degK&longstat=Individual+Obs&DB_statistic=Individual+Obs&stat=&lat-begin=12S&lat-end=12N&lon-begin=5.0E&lon-end=32.5E&dim0=level&level+units=millibar&level=1000.00&dim1=time&year_begin=1948&mon_begin=Jan&day_begin=1&hour_begin=00+Z&year_end=1949&mon_end=Jan&day_end=1&hour_end=00+Z&X=lon&Y=lat&output=file&bckgrnd=black&use_color=on&fill=lines&cint=&range1=&range2=&scale=100&submit=Create+Plot+or+Subset+of+Data

I could create a loop for each variable going through each year, but this will take some manual hacking and i am not completely sure how it might work in a script. Is there a more intuitive or quicker way to download only a subset of the variables and to avoid downloading the global .nc files?

ED crashes due to TopModel Hydrology

I get the error message below trying to run the latest version of ED from mainline. I tracked down the error and found out that "signal 8 (SIGFPE): Floating-point exception." error is due to dividing by 0 in lsm_hyd. The value of "cgrid%Te(ipy)" in denominator remains zero. I can fix this by removing assigning a correct values to "cgrid%Te(ipy)" in the formula but want to check out and see if anyone knows why it is there at the first place since I could not understand why. It seems that Te is the terrestrial area in the polygon which is used in hydrology.
(cpoly%moist_tau(isi) = soil(cpoly%ntext_soil(nzg-1,isi))%slmsts / &
(MoistRateTuning_cpoly%moist_f(isi)_cgrid%Te(ipy)* &
exp(MoistRateTuning_cpoly%moist_f(isi)_min(0.0,cgrid%zbar(ipy))) &
_exp(cgrid%wbar(ipy))_fracliqtotal)


=== Time integration starts (model) ===

  • Simulating: 06/01/2000 00:00:00 UTC

Program received signal 8 (SIGFPE): Floating-point exception.

Backtrace for this error:

  • /lib64/libc.so.6(+0x326a0) [0x2af5500c26a0]
  • function calchydrosubsurface_ (0xA4433C)
    at line 391 of file lsm_hyd.f90
  • function ed_model_ (0x512C0B)
    at line 489 of file ed_model.F90
  • function ed_driver_ (0x434C99)
    at line 297 of file ed_driver.F90
  • in the main program
    at line 285 of file edmain.F90
  • /lib64/libc.so.6(__libc_start_main+0xfd) [0x2af5500aed5d]
    ** Warning: a core dump was requested, but the core sizelimit
    ** is currently zero.

Quit

Met forcing has issues...

I am getting this error message after ED runs for roughly 40 days, simulation starts 1/1/1600. The HDF5 file seems to be fine. Any idea what might be trigger this?

Air specific humidity doesn't make sense...

  • Polygon : 1
    • Site : 1
    • Date : 02/09/1600
    • Time : 09:00:00 UTC
    • Longitude : 1.65000E+01
    • Latitude : 2.50000E+00
    • Site spec. hum.: 3.26690E-02
    • Polygon sp. h. : 3.26690E-02
    • Minimum OK : 1.00000E-06

    - Maximum OK : 3.20000E-02

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::


                 !!! FATAL ERROR !!!                      

---> File:        lapse.f90
---> Subroutine:  met_sanity_check
---> Reason:      Meteorological forcing has issues (check message).

Create ED2-RTM sub directory within ED2/

@rgknox

@mdietze and I would like to add an additional directory within the main ED2 director to house (at least for now) our developing ED2-RTM module code base for our NASA TE project. Right now this is the current structure:

../BRAMS
../cnt_lines.sh
../diff_version.sh
../ED
../EDTS
../Ramspost
../RAPP
../README.md
../R-utils

We would like to add a dir labeled "ED2-RTM" (or something similar if that may conflict with something else) where we develop the code needed to assimilate RS datasets within the ED2 RTM framework, "offline" from the full model. For now, having the separate RTM code base within the main ED2 folder will help with compiling and linking since what we are developing uses existing ED2 libs and functions. Would this be something we can do, at least for the short-term? If it turns out to cause issues (which I don't expect) we could always move it. While we are leveraging existing libs, we are not modifying the mainline.

The other option is to create an additional repo within the EDmodel list of repos for this code.

Thanks!

Portable installation of ED

Maybe this has already been discussed by other people, but given the not so easy installation and compiling of ED, and the many different versions of libraries and compilers, what about making a portable installation of ED? Something I can compile on say the pecan VM and just copy a folder or the ED executable and the ED2IN file to another computer and run. Fortran code can be compiled with the -static option and the exe can include static loaded libraries. It seems from what I have found online that it is also possible to use dlopen and dlsym to dynamically load .so .I tried to compile using some of the -static flags but the executable didn't run on another machine, and I am sure it is more complex than that. If anybody is interested in this please let me know and we can discuss this further.

Too many open files - HDF5 error

My test cases are not properly closing HDF5 files during read and/or writes.

If anyone has a potential solution or can re-create this issue, please comment.

My system is a GNU linux, gfortran 4.8 compiler, and HDF5 1.8.13. I have also reproduced this issue with HDF5 1.8.11 and gfortran 4.6.

Here is an example of the complaint:

HDF5-DIAG: Error detected in HDF5 (1.8.13) thread 0:
#000: H5F.c line 1594 in H5Fopen(): unable to open file
major: File accessibilty
minor: Unable to open file
#1: H5F.c line 1290 in H5F_open(): unable to open file: time = Sat Jul 12 19:56:45 2014
, name = '/home/rgknox/Datasets/m34_tower_manzi/ed_drivers/KM34_EDM2.2_30MIN_2008NOV.h5', tent_flags = 0
major: File accessibilty
minor: Unable to open file
#2: H5FD.c line 985 in H5FD_open(): open failed
major: Virtual File Layer
minor: Unable to initialize object
#3: H5FDsec2.c line 343 in H5FD_sec2_open(): unable to open file: name = '/home/rgknox/Datasets/m34_tower_manzi/ed_drivers/KM34_EDM2.2_30MIN_2008NOV.h5', errno = 24, error message = 'Too many open files', flags = 0, o_flags = 0
major: File accessibilty
minor: Unable to open file
Error opening hdf5 file - error - -1

SIGFPE fault in twostream_rad.f90

2 out of sites just got this error about 65 years into my full runs (post-spin up from bare ground). Haven't tracked it down yet, but wanted to throw it out there incase anybody had any immediate thoughts. It's reproducible, so not an initialization error.


Traceback:

Program received signal 8 (SIGFPE): Floating-point exception.

Backtrace for this error:

  • /lib64/libc.so.6(+0x326a0) [0x2b228971b6a0]
  • /lib64/libm.so.6(+0x12d70) [0x2b2287803d70]
  • /lib64/libm.so.6(log+0x12) [0x2b2287816462]
  • function sw_two_stream_ (0xC02EB1)
    at line 572 of file twostream_rad.f90
  • function sfcrad_ed_.omp_fn.1 (0xAA4752)
    at line 952 of file radiate_driver.f90
  • /usr/lib64/libgomp.so.1(+0x8502) [0x2b22890b0502]
  • /lib64/libpthread.so.0(+0x79d1) [0x2b22894d29d1]
  • /lib64/libc.so.6(clone+0x6d) [0x2b22897d18fd]
    ** Warning: a core dump was requested, but the core sizelimit
    ** is currently zero.


Cited Lines of code in twostream_rad.f90

     !---------------------------------------------------------------------------------!
     !     We find the inverse optical depth of the direct radiation (mu0), following  !
     ! CLM10 (equation 3.3 and text after equation 3.3).                               !
     !---------------------------------------------------------------------------------!
     proj_area(i) = phi1(ipft) + phi2(ipft) * czen
     mu0      (i) = - etai(i)                                                          &
                    / log( ( 1.d0 - cai(i) )                                           &
                         + cai(i) * exp( - proj_area(i) * etai(i)                      &
                                         / ( cai(i) * czen ) ) )
     !---------------------------------------------------------------------------------!


Link to ED2IN & Species Parameterization Settings

ED2IN: https://github.com/crollinson/ED_Processing/blob/master/runs_ED2IN/ED2IN.PHO

PFT Configuration: https://github.com/crollinson/ED_Processing/blob/master/PalEON_Phase1a.v2.xml

I'll take a look at the output sometime in the next couple days and let folks know if it's a problem with my settings and/or if there's a bug that needs to be fixed. I haven't looked at the radiation dynamics though, so of somebody has any thoughts, I'd be really grateful.

To enable or not to enable parallel [in HDF5]? That is the question.

./configure --prefix=/data/software/hdf5/1.8.13 --with-zlib=/data/software/zlib --enable-fortran

Should I also: --enable-parallel ?

I know that when I compile without using that switch configure uses mpi* compilers. I just can not remember if this is specifically needed, particularly with a mpirun/gridded run.

I am having some down-stream issues with not being able to make the latest netCDF:
/usr/bin/ld: /data/software/hdf5/1.8.13/lib/libhdf5_hl.a(H5DS.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/data/software/hdf5/1.8.13/lib/libhdf5_hl.a: could not read symbols: Bad value

And I think this may mean that I need to use the -fPIC compile flag for zlib, HDF4/5 and netCDF which requires a recompile.

Variable is not short [RAPP]

I am running RAPP, but when the code checks whether a variable is nf90_short type the execution stops right away processing the first variable 'air'. I don't know why this check is in place, however by opening air and other variables in HDFView it seems the variables are floating 32-bit. According to the netcdf documentation this should be a NF90_FLOAT. Am I missing something? This is the piece of code within the mod_ncdf_globio

elseif (xtype /= NF90_SHORT) then
call fatal_error('Variable '//trim(varname)//' is not short integer!

Example Computational Profile - Single Tropical Site at Manaus Brazil ZF2

The call graph generated below used the gfortran compiler 4.8, -O2 optimization, 3 months of simulation (short, I know), Euler/BDF2 time-stepping, 20 patches and 80 cohorts. I will paste the ED2IN below. The graph breaks up the computers wall time into the various sub-routines. This is just an example to give people a sense of where ED2 spends its time.

The graph was generated with the gprof profiler, and the gprof2dot python script.

edprof

!==========================================================================================!
!==========================================================================================!
! ED2IN . !
! !
! This is the file that contains the variables that define how ED is to be run. There !
! is some brief information about the variables here. !
!------------------------------------------------------------------------------------------!
$ED_NL

!----- Simulation title (64 characters). -----------------------------------------------!
NL%EXPNME = 'ED version 2.1 test'
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! Type of run: !
! INITIAL -- Starts a new run, that can be based on a previous run (restart/history), !
! but then it will use only the biomass and soil carbon information. !
! HISTORY -- Resumes a simulation from the last history. This is different from !
! initial in the sense that exactly the same information written in the !
! history will be used here. !
!---------------------------------------------------------------------------------------!
NL%RUNTYPE = 'INITIAL'
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! Start of simulation. Information must be given in UTC time. !
!---------------------------------------------------------------------------------------!
NL%IMONTHA = 01
NL%IDATEA = 01
NL%IYEARA = 1500
NL%ITIMEA = 0000
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! End of simulation. Information must be given in UTC time. !
!---------------------------------------------------------------------------------------!
NL%IMONTHZ = 03 ! Month
NL%IDATEZ = 01 ! Day
NL%IYEARZ = 1500
NL%ITIMEZ = 0000 ! UTC
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! DTLSM -- Time step to integrate photosynthesis, and the maximum time step for !
! integration of energy and water budgets (units: seconds). Notice that the !
! model will take steps shorter than this if this is too coarse and could !
! lead to loss of accuracy or unrealistic results in the biophysics. !
! Recommended values are < 60 seconds if INTEGRATION_SCHEME is 0, and 240-900 !
! seconds otherwise. !
! RADFRQ -- Time step to integrate radiation, in seconds. This must be an integer !
! multiple of DTLSM, and we recommend it to be exactly the same as DTLS5BM. !
!---------------------------------------------------------------------------------------!
NL%DTLSM = 180.
NL%RADFRQ = 180.
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! The following variables are used in case the user wants to run a regional run. !
! !
! N_ED_REGION -- number of regions for which you want to run ED. This can be set to !
! zero provided that N_POI is not... !
! GRID_TYPE -- which kind of grid to run: !
! 0. Longitude/latitude grid !
! 1. Polar-stereographic !
!---------------------------------------------------------------------------------------!
NL%N_ED_REGION = 0
NL%GRID_TYPE = 1

  !------------------------------------------------------------------------------------!
  !     The following variables are used only when GRID_TYPE is set to 0.  You must    !
  ! provide one value for each grid, except otherwise noted.                           !
  !                                                                                    !
  ! GRID_RES       -- Grid resolution, in degrees (first grid only, the other grids    !
  !                   resolution will be defined by NSTRATX/NSTRATY).                  !
  ! ED_REG_LATMIN  -- Southernmost point of each region.                               !
  ! ED_REG_LATMAX  -- Northernmost point of each region.                               !
  ! ED_REG_LONMIN  -- Westernmost point of each region.                                !
  ! ED_REG_LONMAX  -- Easternmost point of each region.                                !
  !------------------------------------------------------------------------------------!
  NL%GRID_RES       =    1.0
  NL%ED_REG_LATMIN  =  -12.0, -7.5, 10.0,  -6.0
  NL%ED_REG_LATMAX  =    1.0, -3.5, 15.0,  -1.0
  NL%ED_REG_LONMIN  =  -66.0,-58.5, 70.0, -63.0
  NL%ED_REG_LONMAX  =  -49.0,-54.5, 35.0, -53.0
  !------------------------------------------------------------------------------------!



  !------------------------------------------------------------------------------------!
  !     The following variables are used only when GRID_TYPE is set to 1.              !
  !                                                                                    !
  ! NNXP    -- number of points in the X direction.  One value for each grid.          !
  ! NNYP    -- number of points in the Y direction.  One value for each grid.          !
  ! DELTAX  -- grid resolution in the X direction, near the grid pole.  Units: [  m].  !
  !            this value is used to define the first grid only, other grids are       !
  !            defined using NNSTRATX.                                                 !
  ! DELTAY  -- grid resolution in the Y direction, near the grid pole.  Units: [  m].  !
  !            this value is used to define the first grid only, other grids are       !
  !            defined using NNSTRATX.  Unless you are running some specific tests,    !
  !            both DELTAX and DELTAY should be the same.                              !
  ! POLELAT -- Latitude of the pole point.  Set this close to CENTLAT for a more       !
  !            traditional "square"  domain.  One value for all grids.                 !
  ! POLELON -- Longitude of the pole point.  Set this close to CENTLON for a more      !
  !            traditional "square"  domain.  One value for all grids.                 !
  ! CENTLAT -- Latitude of the central point.  One value for each grid.                !
  ! CENTLON -- Longitude of the central point.  One value for each grid.               !
  !------------------------------------------------------------------------------------!
  NL%NNXP    = 110
  NL%NNYP    =  70
  NL%DELTAX  = 60000.
  NL%DELTAY  = 60000.
  NL%POLELAT =  -2.857
  NL%POLELON = -54.959
  NL%CENTLAT =  -2.857
  NL%CENTLON = -54.959
  !------------------------------------------------------------------------------------!



  !------------------------------------------------------------------------------------!
  !     Nest ratios.  These values are used by both GRID_TYPE=0 and GRID_TYPE=1.       !
  ! NSTRATX --  this is will divide the values given by DELTAX or GRID_RES for the     !
  !             nested grids.  The first value should be always one.                   !
  ! NSTRATY --  this is will divide the values given by DELTAY or GRID_RES for the     !
  !             nested grids.  The first value should be always one, and this must     !
  !             be always the same as NSTRATX when GRID_TYPE = 0, and this is also     !
  !             strongly recommended for when GRID_TYPE = 1.                           !
  !------------------------------------------------------------------------------------!
  NL%NSTRATX = 1,4
  NL%NSTRATY = 1,4
  !------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! The following variables are used to define single polygon of interest runs, and !
! they are ignored when N_ED_REGION = 0. !
! !
! N_POI -- number of polygons of interest (POIs). This can be zero as long as !
! N_ED_REGION is not. !
! POI_LAT -- list of latitudes of each POI. !
! POI_LON -- list of longitudes of each POI. !
! POI_RES -- grid resolution of each POI (degrees). This is used only to define the !
! soil types !
!---------------------------------------------------------------------------------------!
NL%N_POI = 1
NL%POI_LAT = -2.609075
NL%POI_LON = -60.2093
NL%POI_RES = 1.00

!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! LOADMETH -- Load balancing method. This is used only in regional runs run in !
! parallel. !
! 0. Let ED decide the best way of splitting the polygons. Commonest !
! option and default. !
! 1. One of the methods to split polygons based on their previous !
! work load. Developpers only. !
! 2. Try to load an equal number of SITES per node. Useful for when !
! total number of polygon is the same as the total number of cores. !
! 3. Another method to split polygons based on their previous work load. !
! Developpers only. !
!---------------------------------------------------------------------------------------!
NL%LOADMETH = 0
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! ED2 File output. For all the variables 0 means no output and 3 means HDF5 output. !
! !
! IFOUTPUT -- Fast analysis. These are mostly polygon-level averages, and the time !
! interval between files is determined by FRQANL !
! IDOUTPUT -- Daily means (one file per day) !
! IMOUTPUT -- Monthly means (one file per month) !
! IQOUTPUT -- Monthly means of the diurnal cycle (one file per month). The number !
! of points for the diurnal cycle is 86400 / FRQANL !
! IYOUTPUT -- Annual output. !
! ITOUTPUT -- Instantaneous fluxes, mostly polygon-level variables, one file per year. !
! ISOUTPUT -- restart file, for HISTORY runs. The time interval between files is !
! determined by FRQHIS !
!---------------------------------------------------------------------------------------!
NL%IFOUTPUT = 0
NL%IDOUTPUT = 0
NL%IMOUTPUT = 0
NL%IQOUTPUT = 3
NL%IYOUTPUT = 0
NL%ITOUTPUT = 0
NL%ISOUTPUT = 3
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! The following variables control whether site-, patch-, and cohort-level time !
! means and mean sum of squares should be included in the output files or not. !
! !
! Reasons to add them: !
! a. Sub-polygon variables are more comprehensive. !
! b. Explore heterogeneity within a polygon and make interesting analysis. !
! c. More chances to create cool 3-D plots. !
! !
! Reasons to NOT add them: !
! a. Output files will become much larger! !
! b. In regional/coupled runs, the output files will be ridiculously large. !
! c. You may fill up the disk. !
! d. Other people's job may crash due to insufficient disk space. !
! e. You will gain a bad reputation amongst your colleagues. !
! f. And it will be entirely your fault. !
! !
! Either way, polygon-level averages are always included, and so are the instan- !
! taneous site-, patch-, and cohort-level variables needed for resuming the run. !
! !
! IADD_SITE_MEANS -- Add site-level averages to the output (0 = no; 1 = yes) !
! IADD_PATCH_MEANS -- Add patch-level averages to the output (0 = no; 1 = yes) !
! IADD_COHORT_MEANS -- Add cohort-level averages to the output (0 = no; 1 = yes) !
! !
!---------------------------------------------------------------------------------------!
NL%IADD_SITE_MEANS = 1
NL%IADD_PATCH_MEANS = 1
NL%IADD_COHORT_MEANS = 1
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! ATTACH_METADATA -- Flag for attaching metadata to HDF datasets. Attaching metadata !
! will aid new users in quickly identifying dataset descriptions but !
! will compromise I/O performance significantly. !
! 0 = no metadata, 1 = attach metadata !
!---------------------------------------------------------------------------------------!
NL%ATTACH_METADATA = 1
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! UNITFAST -- The following variables control the units for FRQFAST/OUTFAST, and !
! UNITSTATE FRQSTATE/OUTSTATE, respectively. Possible values are: !
! 0. Seconds; !
! 1. Days; !
! 2. Calendar months (variable) !
! 3. Calendar years (variable) !
! !
! N.B.: 1. In case OUTFAST/OUTSTATE are set to special flags (-1 or -2) !
! UNITFAST/UNITSTATE will be ignored for them. !
! 2. In case IQOUTPUT is set to 3, then UNITFAST has to be 0. !
! !
!---------------------------------------------------------------------------------------!
NL%UNITFAST = 0
NL%UNITSTATE = 3
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! OUTFAST/OUTSTATE -- these control the number of times per file. !
! 0. Each time gets its own file !
! -1. One file per day !
! -2. One file per month !
! > 0. Multiple timepoints can be recorded to a single file reducing !
! the number of files and i/o time in post-processing. !
! Multiple timepoints should not be used in the history files !
! if you intend to use these for HISTORY runs. !
!---------------------------------------------------------------------------------------!
NL%OUTFAST = 2
NL%OUTSTATE = 0
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! ICLOBBER -- What to do in case the model finds a file that it was supposed the !
! written? 0 = stop the run, 1 = overwrite without warning. !
! FRQFAST -- time interval between analysis files, units defined by UNITFAST. !
! FRQSTATE -- time interval between history files, units defined by UNITSTATE. !
!---------------------------------------------------------------------------------------!
NL%ICLOBBER = 1
NL%FRQFAST = 3600
NL%FRQSTATE = 5.
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! FFILOUT -- Path and prefix for analysis files (all but history/restart). !
! SFILOUT-- Path and prefix for history files. !
!---------------------------------------------------------------------------------------!
NL%FFILOUT = 'F_test/mstr-953-v0'
NL%SFILOUT = 'S_test/mstr-953-v0'
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! IED_INIT_MODE -- This controls how the plant community and soil carbon pools are !
! initialised. !
! !
! -1. Start from a true bare ground run, or an absolute desert run. This will !
! never grow any plant. !
! 0. Start from near-bare ground (only a few seedlings from each PFT to be included !
! in this run). !
! 1. This will use history files written by ED-1.0. It will grab the ecosystem !
! state (like biomass, LAI, plant density, etc.), but it will start the !
! thermodynamic state as a new simulation. !
! 2. Same as 1, but it uses history files from ED-2.0 without multiple sites, and !
! with the old PFT numbers. !
! 3. Same as 1, but using history files from ED-2.0 with multiple sites and !
! TOPMODEL hydrology. !
! 4. Same as 1, but using ED2.1 H5 history/state files that take the form: !
! 'dir/prefix-gxx.h5' !
! Initialization files MUST end with -gxx.h5 where xx is a two digit integer !
! grid number. Each grid has its own initialization file. As an example, if a !
! user has two files to initialize their grids with: !
! example_file_init-g01.h5 and example_file_init-g02.h5 !
! NL%SFILIN = 'example_file_init' !
! !
! 5. This is similar to option 4, except that you may provide several files !
! (including a mix of regional and POI runs, each file ending at a different !
! date). This will not check date nor grid structure, it will simply read all !
! polygons and match the nearest neighbour to each polygon of your run. SFILIN !
! must have the directory common to all history files that are sought to be used,!
! up to the last character the files have in common. For example if your files !
! are !
! /mypath/P0001-S-2000-01-01-000000-g01.h5, !
! /mypath/P0002-S-1966-01-01-000000-g02.h5, !
! ... !
! /mypath/P1000-S-1687-01-01-000000-g01.h5: !
! NL%SFILIN = '/mypath/P' !
! !
! 6 - Initialize with ED-2 style files without multiple sites, exactly like option !
! 2, except that the PFT types are preserved. !
! !
! 7. Initialize from a list of both POI and gridded ED2.1 state files, organized !
! in the same manner as 5. This method overrides the soil database info and !
! takes the soil texture and soil moisture information from the initializing !
! ED2.1 state file. It allows for different layering, and assigns via nearest !
! neighbor.
!
!
!---------------------------------------------------------------------------------------!
NL%IED_INIT_MODE = 5
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! EDRES -- Expected input resolution for ED2.0 files. This is not used unless !
! IED_INIT_MODE = 3. !
!---------------------------------------------------------------------------------------!
NL%EDRES = 1.0
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! SFILIN -- The meaning and the size of this variable depends on the type of run, set !
! !
! 1. INITIAL. Then this is the path+prefix of the previous ecosystem state. This has !
! dimension of the number of grids so you can initialize each grid with a !
! different dataset. In case only one path+prefix is given, the same will !
! be used for every grid. Only some ecosystem variables will be set up !
! here, and the initial condition will be in thermodynamic equilibrium. !
! !
! 2. HISTORY. This is the path+prefix of the history file that will be used. Only the !
! path+prefix will be used, as the history for every grid must have come !
! from the same simulation. !
!---------------------------------------------------------------------------------------!
! NL%SFILIN='/home/rgknox/Datasets/edts_data/inits/sci_006_potveg_links/PVE'
NL%SFILIN='S_oxi_TF.9PCNT/zf2_oxi_TF.9PCNT-S-2000'
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! History file information. These variables are used to continue a simulation from !
! a point other than the beginning. Time must be in UTC. !
! !
! IMONTHH -- the time of the history file. This is the only place you need to change !
! IDATEH dates for a HISTORY run. You may change IMONTHZ and related in case you !
! IYEARH want to extend the run, but yo should NOT change IMONTHA and related. !
! ITIMEH !
!---------------------------------------------------------------------------------------!
NL%ITIMEH = 0000 ! UTC
NL%IDATEH = 01 ! Day
NL%IMONTHH = 01 ! Month
NL%IYEARH = 1402 ! Year
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! NZG - number of soil layers. One value for all grids. !
! NZS - maximum number of snow/water pounding layers. This is used only for !
! snow, if only liquid water is standing, the water will be all collapsed !
! into a single layer, so if you are running for places where it doesn't snow !
! a lot, leave this set to 1. One value for all grids. !
!---------------------------------------------------------------------------------------!
NL%NZG = 16
NL%NZS = 4
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! ISOILFLG -- this controls which soil type input you want to use. !
! 1. Read in from a dataset I will provide in the SOIL_DATABASE variable a !
! few lines below. !
! below. !
! 2. No data available, I will use constant values I will provide in !
! NSLCON or by prescribing the fraction of sand and clay (see SLXSAND !
! and SLXCLAY). !
!---------------------------------------------------------------------------------------!
NL%ISOILFLG = 1
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! NSLCON -- ED-2 Soil classes that the model will use when ISOILFLG is set to 2. !
! Possible values are: !
!---------------------------------------------------------------------------------------!
! 1 -- sand | 7 -- silty clay loam | 13 -- bedrock !
! 2 -- loamy sand | 8 -- clayey loam | 14 -- silt !
! 3 -- sandy loam | 9 -- sandy clay | 15 -- heavy clay !
! 4 -- silt loam | 10 -- silty clay | 16 -- clayey sand !
! 5 -- loam | 11 -- clay | 17 -- clayey silt !
! 6 -- sandy clay loam | 12 -- peat !
!---------------------------------------------------------------------------------------!
NL%NSLCON = 17 ! Default soil type if ISOILFLG = 2 (choices below:)
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! ISOILCOL -- LEAF-3 and ED-2 soil colour classes that the model will use when ISOILFLG !
! is set to 2. Soil classes are from 1 to 20 (1 = lightest; 20 = darkest). !
! The values are the same as CLM-4.0. The table is the albedo for visible !
! and near infra-red. !
!---------------------------------------------------------------------------------------!
! !
! |-----------------------------------------------------------------------| !
! | | Dry soil | Saturated | | Dry soil | Saturated | !
! | Class |-------------+-------------| Class +-------------+-------------| !
! | | VIS | NIR | VIS | NIR | | VIS | NIR | VIS | NIR | !
! |-------+------+------+------+------+-------+------+------+------+------| !
! | 1 | 0.36 | 0.61 | 0.25 | 0.50 | 11 | 0.24 | 0.37 | 0.13 | 0.26 | !
! | 2 | 0.34 | 0.57 | 0.23 | 0.46 | 12 | 0.23 | 0.35 | 0.12 | 0.24 | !
! | 3 | 0.32 | 0.53 | 0.21 | 0.42 | 13 | 0.22 | 0.33 | 0.11 | 0.22 | !
! | 4 | 0.31 | 0.51 | 0.20 | 0.40 | 14 | 0.20 | 0.31 | 0.10 | 0.20 | !
! | 5 | 0.30 | 0.49 | 0.19 | 0.38 | 15 | 0.18 | 0.29 | 0.09 | 0.18 | !
! | 6 | 0.29 | 0.48 | 0.18 | 0.36 | 16 | 0.16 | 0.27 | 0.08 | 0.16 | !
! | 7 | 0.28 | 0.45 | 0.17 | 0.34 | 17 | 0.14 | 0.25 | 0.07 | 0.14 | !
! | 8 | 0.27 | 0.43 | 0.16 | 0.32 | 18 | 0.12 | 0.23 | 0.06 | 0.12 | !
! | 9 | 0.26 | 0.41 | 0.15 | 0.30 | 19 | 0.10 | 0.21 | 0.05 | 0.10 | !
! | 10 | 0.25 | 0.39 | 0.14 | 0.28 | 20 | 0.08 | 0.16 | 0.04 | 0.08 | !
! |-----------------------------------------------------------------------| !
! !
! Soil type 21 is a special case in which we use the albedo method that used to be !
! the default in ED-2.1. !
!---------------------------------------------------------------------------------------!
NL%ISOILCOL = 2
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! These variables are used to define the soil properties when you don't want to use !
! the standard soil classes. !
! !
! SLXCLAY -- Prescribed fraction of clay [0-1] !
! SLXSAND -- Prescribed fraction of sand [0-1]. !
! !
! They are used only when ISOILFLG is 2, both values are between 0. and 1., and !
! theira sum doesn't exceed 1. Otherwise standard ED values will be used instead. !
!---------------------------------------------------------------------------------------!
! THIS SHOULD DICTATE THE NUMBER OF SITES IF AN SOI AND ISOILCOL=2

NL%SLXCLAY = 0.70
NL%SLXSAND = 0.20
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! Soil grid and initial conditions if no file is provided: !
! !
! SLZ - soil depth in m. Values must be negative and go from the deepest layer to !
! the top. !
! SLMSTR - this is the initial soil moisture, now given as the soil moisture index. !
! Values can be fraction, in which case they will be linearly interpolated !
! between the special points (e.g. 0.5 will put soil moisture half way !
! between the wilting point and field capacity). !
! -1 = dry air soil moisture !
! 0 = wilting point !
! 1 = field capacity !
! 2 = porosity (saturation) !
! STGOFF - initial temperature offset (soil temperature = air temperature + offset) !
!---------------------------------------------------------------------------------------!
NL%SLZ = -8.000,-6.959,-5.995,-5.108,-4.296,-3.560,-2.897,-2.307,-1.789,-1.340,
-0.961,-0.648,-0.400,-0.215,-0.089,-0.020
NL%SLMSTR = 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000,
1.000, 1.000, 1.000, 1.000, 1.000, 1.000
NL%STGOFF = 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000,
0.000, 0.000, 0.000, 0.000, 0.000, 0.000
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! Input databases !
! VEG_DATABASE -- vegetation database, used only to determine the land/water mask. !
! Fill with the path and the prefix. !
! SOIL_DATABASE -- soil database, used to determine the soil type. Fill with the !
! path and the prefix. !
! LU_DATABASE -- land-use change disturbance rates database, used only when !
! IANTH_DISTURB is set to 1. Fill with the path and the prefix. !
! PLANTATION_FILE -- plantation fraction file. In case you don't have such a file or !
! you do not want to use it, you must leave this variable empty: !
! (NL%PLANTATION_FILE = '' !
! THSUMS_DATABASE -- input directory with dataset to initialise chilling degrees and !
! growing degree days, which is used to drive the cold-deciduous !
! phenology (you must always provide this, even when your PFTs are !
! not cold deciduous). !
! ED_MET_DRIVER_DB -- File containing information for meteorological driver !
! instructions (the "header" file). !
! SOILSTATE_DB -- Dataset in case you want to provide the initial conditions of !
! soil temperature and moisture. !
! SOILDEPTH_DB -- Dataset in case you want to read in soil depth information. !
!---------------------------------------------------------------------------------------!
NL%VEG_DATABASE = 'edts_datasets/veg_oge/OGE2_'
NL%SOIL_DATABASE = 'edts_datasets/soils/Quesada+RADAM+IGBP/Quesada+RADAM+IGBP_'
NL%LU_DATABASE = 'edts_datasets/land_use/glu+sa2/blend-'
NL%PLANTATION_FILE = ''
NL%THSUMS_DATABASE = 'edts_datasets/ed_inputs/'
NL%ED_MET_DRIVER_DB = '/data1/Datasets/m34_tower_manzi/ed_drivers/km34_1500-2200/ED_KM34_1500-2200_DRIVER_HEADER'
NL%SOILSTATE_DB = ''
NL%SOILDEPTH_DB = ''
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! ISOILSTATEINIT -- Variable controlling how to initialise the soil temperature and !
! moisture !
! 0. Use SLMSTR and STGOFF. !
! 1. Read from SOILSTATE_DB. !
! ISOILDEPTHFLG -- Variable controlling how to initialise soil depth !
! 0. Constant, always defined by the first SLZ layer. !
! 1. Read from SOILDEPTH_DB. !
!---------------------------------------------------------------------------------------!
NL%ISOILSTATEINIT = 0
NL%ISOILDEPTHFLG = 0
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! ISOILBC -- This controls the soil moisture boundary condition at the bottom. Choose !
! the option according to the site characteristics. !
! 0. Flat bedrock. Flux from the bottom of the bottommost layer is zero. !
! 1. Gravitational flow (free drainage). The flux from the bottom of the !
! bottommost layer is due to gradient of height only. !
! 2. Lateral drainage. Similar to free drainage, but the gradient is !
! reduced by the slope not being completely vertical. The reduction is !
! controlled by variable SLDRAIN. In the future options 0, 1, and 2 may !
! be combined into a single option. !
! 3. Aquifer. Soil moisture of the ficticious layer beneath the bottom is !
! always at saturation. !
!---------------------------------------------------------------------------------------!
NL%ISOILBC = 1
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! SLDRAIN -- This is used only when ISOILBC is set to 2. In this case SLDRAIN is the !
! equivalent slope that will slow down drainage. If this is set to zero, !
! then lateral drainage reduces to flat bedrock, and if this is set to 90, !
! then lateral drainage becomes free drainage. SLDRAIN must be between 0 !
! and 90. !
!---------------------------------------------------------------------------------------!
NL%SLDRAIN = 10.
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! IVEGT_DYNAMICS -- The vegetation dynamics scheme. !
! 0. No vegetation dynamics, the initial state will be preserved, !
! even though the model will compute the potential values. This !
! option is useful for theoretical simulations only. !
! 1. Normal ED vegetation dynamics (Moorcroft et al 2001). !
! The normal option for almost any simulation. !
!---------------------------------------------------------------------------------------!
NL%IVEGT_DYNAMICS = 1
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! IBIGLEAF -- Do you want to run ED as a 'big leaf' model? !
! 0. No, use the standard size- and age-structure (Moorcroft et al. 2001) !
! This is the recommended method for most applications. !
! 1. 'big leaf' ED: this will have no horizontal or vertical hetero- !
! geneities; 1 patch per PFT and 1 cohort per patch; no vertical !
! growth, recruits will 'appear' instantaneously at maximum height. !
! !
! N.B. if you set IBIGLEAF to 1, you MUST turn off the crown model (CROWN_MOD = 0) !
!---------------------------------------------------------------------------------------!
NL%IBIGLEAF = 0
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! INTEGRATION_SCHEME -- The biophysics integration scheme. !
! 0. Euler step. The fastest, but it doesn't estimate !
! errors. !
! 1. Fourth-order Runge-Kutta method. ED-2.1 default method !
! 2. Heun's method (a second-order Runge-Kutta). !
! 3. Hybrid Stepping (BDF2 implicit step for the canopy air and !
! leaf temp, forward Euler for else, under development). !
!---------------------------------------------------------------------------------------!
NL%INTEGRATION_SCHEME = 3
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! RK4_TOLERANCE -- This is the relative tolerance for Runge-Kutta or Heun's !
! integration. Larger numbers will make runs go faster, at the !
! expense of being less accurate. Currently the valid range is !
! between 1.e-7 and 1.e-1, but recommended values are between 1.e-4 !
! and 1.e-2. !
!---------------------------------------------------------------------------------------!
NL%RK4_TOLERANCE = 0.01
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! IBRANCH_THERMO -- This determines whether branches should be included in the !
! vegetation thermodynamics and radiation or not. !
! 0. No branches in energy/radiation (ED-2.1 default); !
! 1. Branches are accounted in the energy and radiation. Branchwood !
! and leaf are treated separately in the canopy radiation scheme, !
! but solved as a single pool in the biophysics integration. !
! 2. Similar to 1, but branches are treated as separate pools in the !
! biophysics (thus doubling the number of prognostic variables). !
!---------------------------------------------------------------------------------------!
NL%IBRANCH_THERMO = 1
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! IPHYSIOL -- This variable will determine the functional form that will control how !
! the various parameters will vary with temperature, and how the CO2 !
! compensation point for gross photosynthesis (Gamma_) will be found. !
! Options are: !
! !
! 0 -- Original ED-2.1, we use the "Arrhenius" function as in Foley et al. (1996) and !
! Moorcroft et al. (2001). Gamma_ is found using the parameters for tau as in !
! Foley et al. (1996). !
! 1 -- Modified ED-2.1. In this case Gamma* is found using the Michaelis-Mentel !
! coefficients for CO2 and O2, as in Farquhar et al. (1980) and in CLM. !
! 2 -- Collatz et al. (1991). We use the power (Q10) equations, with Collatz et al. !
! parameters for compensation point, and the Michaelis-Mentel coefficients. The !
! correction for high and low temperatures are the same as in Moorcroft et al. !
! (2001). !
! 3 -- Same as 2, except that we find Gamma* as in Farquhar et al. (1980) and in CLM. !
!---------------------------------------------------------------------------------------!
NL%IPHYSIOL = 2
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! IALLOM -- Which allometry to use (this mostly affects tropical PFTs. Temperate PFTs !
! will use the new root allometry and the maximum crown area if IALLOM is set !
! to 1 or 2). !
! 0. Original ED-2.1 !
! 1. a. The coefficients for structural biomass are set so the total AGB !
! is similar to Baker et al. (2004), equation 2. Balive is the !
! default ED-2.1; !
! b. Experimental root depth that makes canopy trees to have root depths !
! of 5m and grasses/seedlings at 0.5 to have root depth of 0.5 m. !
! c. Crown area defined as in Poorter et al. (2006), imposing maximum !
! crown area !
! 2. Similar to 1, but with a few extra changes. !
! a. Height -> DBH allometry as in Poorter et al. (2006) !
! b. Balive is retuned, using a few leaf biomass allometric equations for !
! a few genuses in Costa Rica. References: !
! Cole and Ewel (2006), and Calvo Alvarado et al. (2008). !
!---------------------------------------------------------------------------------------!
NL%IALLOM = 2
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! IGRASS -- This controls the dynamics and growth calculation for grasses. A new !
! grass scheme is now available where bdead = 0, height is a function of bleaf!
! and growth happens daily. ALS (3/3/12) !
! 0: grasses behave like trees as in ED2.1 (old scheme) !
! !
! 1: new grass scheme as described above !
!---------------------------------------------------------------------------------------!
NL%IGRASS = 1
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! IPHEN_SCHEME -- It controls the phenology scheme. Even within each scheme, the !
! actual phenology will be different depending on the PFT. !
! !
! -1: grasses - evergreen; !
! tropical - evergreen; !
! conifers - evergreen; !
! hardwoods - cold-deciduous (Botta et al.); !
! !
! 0: grasses - drought-deciduous (old scheme); !
! tropical - drought-deciduous (old scheme); !
! conifers - evergreen; !
! hardwoods - cold-deciduous; !
! !
! 1: prescribed phenology !
! !
! 2: grasses - drought-deciduous (new scheme); !
! tropical - drought-deciduous (new scheme); !
! conifers - evergreen; !
! hardwoods - cold-deciduous; !
! !
! 3: grasses - drought-deciduous (new scheme); !
! tropical - drought-deciduous (light phenology); !
! conifers - evergreen; !
! hardwoods - cold-deciduous; !
! !
! Old scheme: plants shed their leaves once instantaneous amount of available water !
! becomes less than a critical value. !
! New scheme: plants shed their leaves once a 10-day running average of available !
! water becomes less than a critical value. !
!---------------------------------------------------------------------------------------!
NL%IPHEN_SCHEME = 2
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! Parameters that control the phenology response to radiation, used only when !
! IPHEN_SCHEME = 3. !
! !
! RADINT -- Intercept !
! RADSLP -- Slope. !
!---------------------------------------------------------------------------------------!
NL%RADINT = -10.3868
NL%RADSLP = 0.0724
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! REPRO_SCHEME -- This controls plant reproduction and dispersal. !
! 0. Reproduction off. Useful for very short runs only. !
! 1. Original reproduction scheme. Seeds are exchanged between !
! patches belonging to the same site, but they can't go outside !
! their original site. !
! 2. Similar to 1, but seeds are exchanged between patches belonging !
! to the same polygon, even if they are in different sites. They !
! can't go outside their original polygon, though. This is the !
! same as option 1 if there is only one site per polygon. !
! 3. Similar to 2, but recruits will only be formed if their phenology !
! status would be "leaves fully flushed". This only matters for !
! drought deciduous plants. This option is for testing purposes !
! only, think 50 times before using it... !
!---------------------------------------------------------------------------------------!
NL%REPRO_SCHEME = 2
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! LAPSE_SCHEME -- This specifies the met lapse rate scheme: !
! 0. No lapse rates !
! 1. phenomenological, global !
! 2. phenomenological, local (not yet implemented) !
! 3. mechanistic(not yet implemented) !
!---------------------------------------------------------------------------------------!
NL%LAPSE_SCHEME = 0
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! CROWN_MOD -- Specifies how tree crowns are represent in the canopy radiation model, !
! and in the turbulence scheme depending on ICANTURB. !
! 0. ED1 default, crowns are evenly spread throughout the patch area, and !
! cohorts are stacked on the top of each other. !
! 1. Dietze (2008) model. Cohorts have a finite radius, and cohorts are !
! stacked on the top of each other. !
!---------------------------------------------------------------------------------------!
NL%CROWN_MOD = 0
!---------------------------------------------------------------------------------------!
NL%VMFACT_C3 = 1.00
NL%VMFACT_C4 = 1.00
NL%MPHOTO_TRC3 = 9.0
NL%MPHOTO_TEC3 = 7.2
NL%MPHOTO_C4 = 5.2
NL%BPHOTO_BLC3 = 10000.
NL%BPHOTO_NLC3 = 1000.
NL%BPHOTO_C4 = 10000.
NL%KW_GRASS = 900.
NL%KW_TREE = 600.
NL%GAMMA_C3 = 0.015
NL%GAMMA_C4 = 0.040
NL%D0_GRASS = 0.016
NL%D0_TREE = 0.016
NL%ALPHA_C3 = 0.080
NL%ALPHA_C4 = 0.055
NL%KLOWCO2IN = 4000.
NL%RRFFACT = 1.000
NL%GROWTHRESP = 0.333
NL%LWIDTH_GRASS = 0.05
NL%LWIDTH_BLTREE = 0.10
NL%LWIDTH_NLTREE = 0.05
NL%Q10_C3 = 2.4
NL%Q10_C4 = 2.4
!---------------------------------------------------------------------------------------!
! The following variables control the canopy radiation solver. !
! !
! ICANRAD -- Specifies how canopy radiation is solved. This variable sets both !
! shortwave and longwave. !
! 0. Two-stream model (Medvigy 2006), with the possibility to apply !
! finite crown area to direct shortwave radiation. !
! 1. Multiple-scattering model (Zhao and Qualls 2005,2006), with the !
! possibility to apply finite crown area to all radiation fluxes. !
! LTRANS_VIS -- Leaf transmittance for tropical plants - Visible/PAR !
! LTRANS_NIR -- Leaf transmittance for tropical plants - Near Infrared !
! LREFLECT_VIS -- Leaf reflectance for tropical plants - Visible/PAR !
! LREFLECT_NIR -- Leaf reflectance for tropical plants - Near Infrared !
! ORIENT_TREE -- Leaf orientation factor for tropical trees. Extremes are: !
! -1. All leaves are oriented in the vertical !
! 0. Leaf orientation is perfectly random !
! 1. All leaves are oriented in the horizontal !
! In practice, acceptable values range from -0.4 and 0.6 !
! ORIENT_GRASS -- Leaf orientation factor for tropical grasses. Extremes are: !
! -1. All leaves are oriented in the vertical !
! 0. Leaf orientation is perfectly random !
! 1. All leaves are oriented in the horizontal !
! In practice, acceptable values range from -0.4 and 0.6 !
! CLUMP_TREE -- Clumping factor for tropical trees. Extremes are: !
! lim -> 0. Black hole (0 itself is unacceptable) !
! 1. Homogeneously spread over the layer (i.e., no clumping) !
! CLUMP_GRASS -- Clumping factor for tropical grasses. Extremes are: !
! lim -> 0. Black hole (0 itself is unacceptable) !
! 1. Homogeneously spread over the layer (i.e., no clumping) !
!---------------------------------------------------------------------------------------!
NL%LTRANS_VIS = 0.060
NL%LTRANS_NIR = 0.200
NL%LREFLECT_VIS = 0.120
NL%LREFLECT_NIR = 0.300
NL%ORIENT_TREE = 0.050
NL%ORIENT_GRASS = -0.200
NL%CLUMP_TREE = 0.800
NL%CLUMP_GRASS = 0.900
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! The following variables control the canopy radiation solver. !
! !
! ICANRAD -- Specifies how canopy radiation is solved. This variable sets both !
! shortwave and longwave. !
! 0. Two-stream model (Medvigy 2006), with the possibility to apply !
! finite crown area to direct shortwave radiation. !
! 1. Multiple-scattering model (Zhao and Qualls 2005,2006), with the !
! possibility to apply finite crown area to all radiation fluxes. !
!---------------------------------------------------------------------------------------!
NL%ICANRAD = 2
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! DECOMP_SCHEME -- This specifies the dependence of soil decomposition on temperature. !
! 0. ED-2.1 default, the original exponential (low temperature !
! limitation only). !
! 1. Lloyd and Taylor (1994) model !
! [[option 1 requires parameters to be set in xml]] !
! 2. Similar to ED-1.0 and CENTURY model, heterotrophic respiration !
! reaches a maximum at around 38C (using the default parameters), !
! then quickly falls to zero at around 50C. It applies a similar !
! function for soil moisture, which allows higher decomposition !
! rates when it is close to the optimal, plumetting when it is !
! almost saturated. !
!---------------------------------------------------------------------------------------!
NL%DECOMP_SCHEME = 0
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! H2O_PLANT_LIM -- this determines whether plant photosynthesis can be limited by !
! soil moisture, the FSW, defined as FSW = Supply / (Demand + Supply). !
! !
! Demand is always the transpiration rates in case soil moisture is !
! not limiting (the psi_0 term times LAI). The supply is determined !
! by Kw * nplant * Broot * Available_Water, and the definition of !
! available water changes depending on H2O_PLANT_LIM: !
! 0. Force FSW = 1 (effectively available water is infinity). !
! 1. Available water is the total soil water above wilting point, !
! integrated across all layers within the rooting zone. !
! 2. Available water is the soil water at field capacity minus !
! wilting point, scaled by the so-called wilting factor: !
! (psi(k) - (H - z(k)) - psi_wp) / (psi_fc - psi_wp) !
! where psi is the matric potentital at layer k, z is the layer !
! depth, H it the crown height and psi_fc and psi_wp are the !
! matric potentials at wilting point and field capacity. !
!---------------------------------------------------------------------------------------!
NL%H2O_PLANT_LIM = 2
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! IDDMORT_SCHEME -- This flag determines whether storage should be accounted in the !
! carbon balance. !
! 0 -- Carbon balance is done in terms of fluxes only. This is the !
! default in ED-2.1 !
! 1 -- Carbon balance is offset by the storage pool. Plants will be !
! in negative carbon balance only when they run out of storage !
! and are still losing more carbon than gaining. !
! !
! DDMORT_CONST -- This constant (k) determines the relative contribution of light !
! and soil moisture to the density-dependent mortality rate. Values !
! range from 0 (soil moisture only) to 1 (light only). !
! !
! mort1 !
! mu_DD = ------------------------- !
! 1 + exp [ mort2 * cr ] !
! !
! CB CB !
! cr = k ------------- + (1 - k) ------------- !
! CB_lightmax CB_watermax !
!---------------------------------------------------------------------------------------!
NL%IDDMORT_SCHEME = 0
NL%DDMORT_CONST = 1.0
NL%CBR_SCHEME = 2
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! THETACRIT -- Leaf drought phenology threshold. The sign matters here: !
! >= 0. -- This is the relative soil moisture above the wilting point !
! below which the drought-deciduous plants will start shedding !
! their leaves !
! < 0. -- This is the soil potential in MPa below which the drought- !
! -deciduous plants will start shedding their leaves. The wilt- !
! ing point is by definition -1.5MPa, so make sure that the value !
! is above -1.5. !
!---------------------------------------------------------------------------------------!
NL%THETACRIT = -1.20
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! QUANTUM_EFFIIENCY_T -- Which quantum yield model should to use for C3 plants !
! 0. Original ED-2.1, quantum efficiency is constant. !
! 1. Quantum efficiency varies with temperature following !
! Ehleringer (1978) polynomial fit. !
!---------------------------------------------------------------------------------------!
NL%QUANTUM_EFFICIENCY_T = 0
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! N_PLANT_LIM -- This controls whether plant photosynthesis can be limited by nitrogen. !
! 0. No limitation !
! 1. ED-2.1 nitrogen limitation model. !
!---------------------------------------------------------------------------------------!
NL%N_PLANT_LIM = 0
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! N_DECOMP_LIM -- This controls whether decomposition can be limited by nitrogen. !
! 0. No limitation !
! 1. ED-2.1 nitrogen limitation model. !
!---------------------------------------------------------------------------------------!
NL%N_DECOMP_LIM = 0
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! The following parameters adjust the fire disturbance in the model. !
! INCLUDE_FIRE -- Which threshold to use for fires. !
! 0. No fires; !
! 1. (deprecated) Fire will be triggered with enough biomass and !
! integrated ground water depth less than a threshold. Based on !
! ED-1, the threshold assumes that the soil is 1 m, so deeper !
! soils will need to be much drier to allow fires to happen and !
! often will never allow fires. !
! 2. Fire will be triggered with enough biomass and the total soil !
! water at the top 75 cm falls below a threshold. !
! 3. Fire will be triggered with enough biomass and accumulated !
! water deficit exceeds the threshold given by SM_FIRE times. !
! the total precipitation of the past 12 months. This method !
! does not directly depend on soil texture. !
! FIRE_PARAMETER -- If fire happens, this will control the intensity of the disturbance !
! given the amount of fuel (currently the total above-ground !
! biomass). !
! SM_FIRE -- This is used only when INCLUDE_FIRE = 2 or 3, and it has different !
! meanings. The sign here matters. !
! When INCLUDE_FIRE = 2: !
! >= 0. - Minimum relative soil moisture above dry air of the top !
! 1m that will prevent fires to happen. !
! < 0. - Minimum mean soil moisture potential in MPa of the top !
! 1m that will prevent fires to happen. The dry air soil !
! potential is defined as -3.1 MPa, so make sure SM_FIRE !
! is greater than this value. !
! When INCLUDE_FIRE = 3, values between 0 and 2 are allowed. This is !
! the minimum water deficit relative to the total rainfall, over the !
! past 12 months, to trigger fires. !
!---------------------------------------------------------------------------------------!
NL%INCLUDE_FIRE = 2
NL%FIRE_PARAMETER = 0.5
NL%SM_FIRE = -1.40
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! IANTH_DISTURB -- This flag controls whether to include anthropogenic disturbances !
! such as land clearing, abandonment, and logging. !
! 0. no anthropogenic disturbance. !
! 1. use anthropogenic disturbance dataset. !
!---------------------------------------------------------------------------------------!
NL%IANTH_DISTURB = 0
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! ICANTURB -- This flag controls the canopy roughness. !
! 0. Based on Leuning et al. (1995) and LEAF-3 (Walko et al. 2000). !
! Roughness and displacement height are found using simple relations !
! with vegetation height; wind is computed using the similarity theory !
! for the top cohort, then it is assumed that wind extinguishes follow- !
! ing an exponential decay with "perceived" cumulative LAI (local LAI !
! with finite crown area). !
! 1. The default ED-2.1 scheme, similar to option 0, but the wind profile !
! is not based on LAI, instead it used the cohort height. !
! 2. This uses the method of Massman (1997) using constant drag and no !
! sheltering factor. !
! 3. This is also based on Massman (1997), but with the option of varying !
! the drag and sheltering within the canopy. !
! 4. Same as 0, but if finds the ground conductance following CLM !
! technical note (equations 5.98-5.100). !
!---------------------------------------------------------------------------------------!
NL%ICANTURB = 3
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! ISFCLYRM -- Similarity theory model. The model that computes u_, T_, etc... !
! 1. BRAMS default, based on Louis (1979). It uses empirical relations to !
! estimate the flux based on the bulk Richardson number !
! !
! All models below use an interative method to find z/L, and the only change !
! is the functional form of the psi functions. !
! !
! 2. Oncley and Dudhia (1995) model, based on MM5. !
! 3. Beljaars and Holtslag (1991) model. Similar to 2, but it uses an alternative !
! method for the stable case that mixes more than the OD95. !
! 4. CLM (2004). Similar to 2 and 3, but they have special functions to deal with !
! very stable and very stable cases. !
!---------------------------------------------------------------------------------------!
NL%ISFCLYRM = 3
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! IED_GRNDVAP -- Methods to find the ground -> canopy conductance. !
! 0. Modified Lee Pielke (1992), adding field capacity, but using beta factor !
! without the square, like in Noilhan and Planton (1989). This is the closest !
! to the original ED-2.0 and LEAF-3, and it is also the recommended one. !
! 1. Test # 1 of Mahfouf and Noilhan (1991) !
! 2. Test # 2 of Mahfouf and Noilhan (1991) !
! 3. Test # 3 of Mahfouf and Noilhan (1991) !
! 4. Test # 4 of Mahfouf and Noilhan (1991) !
! 5. Combination of test #1 (alpha) and test #2 (soil resistance). !
! In all cases the beta term is modified so it approaches zero as soil moisture goes !
! to dry air soil. !
!---------------------------------------------------------------------------------------!
NL%IED_GRNDVAP = 0
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! The following variables are used to control the similarity theory model. For the !
! meaning of these parameters, check Beljaars and Holtslag (1991). !
! GAMM -- gamma coefficient for momentum, unstable case (dimensionless) !
! Ignored when ISTAR = 1 !
! GAMH -- gamma coefficient for heat, unstable case (dimensionless) !
! Ignored when ISTAR = 1 !
! TPRANDTL -- Turbulent Prandtl number !
! Ignored when ISTAR = 1 !
! RIBMAX -- maximum bulk Richardson number. !
! LEAF_MAXWHC -- Maximum water that can be intercepted by leaves, in kg/m2leaf. !
!---------------------------------------------------------------------------------------!
NL%GAMM = 13.0
NL%GAMH = 13.0
NL%TPRANDTL = 0.74
NL%RIBMAX = 0.50
NL%LEAF_MAXWHC = 0.11
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! IPERCOL -- This controls percolation and infiltration. !
! 0. Default method. Assumes soil conductivity constant and for the !
! temporary surface water, it sheds liquid in excess of a 1:9 liquid- !
! -to-ice ratio through percolation. Temporary surface water exists !
! only if the top soil layer is at saturation. !
! 1. Constant soil conductivity, and it uses the percolation model as in !
! Anderson (1976) NOAA technical report NWS 19. Temporary surface !
! water may exist after a heavy rain event, even if the soil doesn't !
! saturate. Recommended value. !
! 2. Soil conductivity decreases with depth even for constant soil moisture !
! , otherwise it is the same as 1. !
!---------------------------------------------------------------------------------------!
NL%IPERCOL = 0
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! The following variables control the plant functional types (PFTs) that will be !
! used in this simulation. !
! !
! INCLUDE_THESE_PFT -- a list containing all the PFTs you want to include in this run !
! AGRI_STOCK -- which PFT should be used for agriculture !
! (used only when IANTH_DISTURB = 1) !
! PLANTATION_STOCK -- which PFT should be used for plantation !
! (used only when IANTH_DISTURB = 1) !
! !
! PFT table !
!---------------------------------------------------------------------------------------!
! 1 - C4 grass | 9 - early temperate deciduous !
! 2 - early tropical | 10 - mid temperate deciduous !
! 3 - mid tropical | 11 - late temperate deciduous !
! 4 - late tropical | 12:15 - agricultural PFTs !
! 5 - temperate C3 grass | 16 - Subtropical C3 grass !
! 6 - northern pines | (C4 grass with C3 photo). !
! 7 - southern pines | 17 - "Araucaria" (non-optimised !
! 8 - late conifers | Southern Pines). !
!---------------------------------------------------------------------------------------!
NL%INCLUDE_THESE_PFT = 1,2,3,4,16
NL%AGRI_STOCK = 1
NL%PLANTATION_STOCK = 3
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! PFT_1ST_CHECK -- What to do if the initialisation file has a PFT that is not listed !
! in INCLUDE_THESE_PFT (ignored if IED_INIT_MODE is -1 or 0) !
! 0. Stop the run !
! 1. Add the PFT in the INCLUDE_THESE_PFT list !
! 2. Ignore the cohort !
!---------------------------------------------------------------------------------------!
NL%PFT_1ST_CHECK = 0
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! The following variables control the size of sub-polygon structures in ED-2. !
! MAXSITE -- This is the strict maximum number of sites that each polygon can !
! contain. Currently this is used only when the user wants to run !
! the same polygon with multiple soil types. If there aren't that !
! many different soil types with a minimum area (check MIN_SITE_AREA !
! below), then the model will allocate just the amount needed. !
! MAXPATCH -- If number of patches in a given site exceeds MAXPATCH, force patch !
! fusion. If MAXPATCH is 0, then fusion will never happen. If !
! MAXPATCH is negative, then the absolute value is used only during !
! the initialization, and fusion will never happen again. Notice !
! that if the patches are too different, then the actual number of !
! patches in a site may exceed MAXPATCH. !
! MAXCOHORT -- If number of cohorts in a given patch exceeds MAXCOHORT, force !
! cohort fusion. If MAXCOHORT is 0, then fusion will never happen. !
! If MAXCOHORT is negative, then the absolute value is used only !
! during the initialization, and fusion will never happen again. !
! Notice that if the cohorts are too different, then the actual !
! number of cohorts in a patch may exceed MAXCOHORT. !
! MIN_SITE_AREA -- This is the minimum fraction area of a given soil type that allows !
! a site to be created (ignored if IED_INIT_MODE is set to 3). !
! MIN_PATCH_AREA -- This is the minimum fraction area of a given soil type that allows !
! a site to be created (ignored if IED_INIT_MODE is set to 3). !
!---------------------------------------------------------------------------------------!
NL%MAXSITE = 1
NL%MAXPATCH = 20
NL%MAXCOHORT = 80
NL%MIN_SITE_AREA = 0.005
NL%MIN_PATCH_AREA = 0.005
!---------------------------------------------------------------------------------------!
!---------------------------------------------------------------------------------------!
! ZROUGH -- constant roughness, in metres, if for all domain !
!---------------------------------------------------------------------------------------!
NL%ZROUGH = 0.1
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! Treefall disturbance parameters. !
! TREEFALL_DISTURBANCE_RATE -- Sign-dependent treefall disturbance rate: !
! > 0. usual disturbance rate, in 1/years; !
! = 0. No treefall disturbance; !
! < 0. Treefall will be added as a mortality rate (it !
! will kill plants, but it won't create a new patch). !
! TIME2CANOPY -- Minimum patch age for treefall disturbance to happen. !
! If TREEFALL_DISTURBANCE_RATE = 0., this value will be !
! ignored. If this value is different than zero, then !
! TREEFALL_DISTURBANCE_RATE is internally adjusted so the !
! average patch age is still 1/TREEFALL_DISTURBANCE_RATE !
!---------------------------------------------------------------------------------------!
NL%TREEFALL_DISTURBANCE_RATE = 0.09
NL%TIME2CANOPY = 0.
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! RUNOFF_TIME -- In case a temporary surface water (TSW) is created, this is the "e- !
! -folding lifetime" of the TSW in seconds due to runoff. If you don't !
! want runoff to happen, set this to 0. !
!---------------------------------------------------------------------------------------!
NL%RUNOFF_TIME = 3600.
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! The following variables control the minimum values of various velocities in the !
! canopy. This is needed to avoid the air to be extremely still, or to avoid singular- !
! ities. When defining the values, keep in mind that UBMIN >= UGBMIN >= USTMIN. !
! !
! UBMIN -- minimum wind speed at the top of the canopy air space [ m/s] !
! UGBMIN -- minimum wind speed at the leaf level [ m/s] !
! USTMIN -- minimum friction velocity, u*, in m/s. [ m/s] !
!---------------------------------------------------------------------------------------!
NL%UBMIN = 0.65
NL%UGBMIN = 0.25
NL%USTMIN = 0.05
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! Control parameters for printing to standard output. Any variable can be printed !
! to standard output as long as it is one dimensional. Polygon variables have been !
! tested, no gaurtantees for other hierarchical levels. Choose any variables that are !
! defined in the variable table fill routine in ed_state_vars.f90. Choose the start !
! and end index of the polygon,site,patch or cohort. It should work in parallel. The !
! indices are global indices of the entire domain. The are printed out in rows of 10 !
! columns each. !
! !
! IPRINTPOLYS -- 0. Do not print information to screen !
! 1. Print polygon arrays to screen, use variables described below to !
! determine which ones and how !
! NPVARS -- Number of variables to be printed !
! PRINTVARS -- List of variables to be printed !
! PFMTSTR -- The standard fortran format for the prints. One format per variable !
! IPMIN -- First polygon (absolute index) to be print !
! IPMAX -- Last polygon (absolute index) to print !
!---------------------------------------------------------------------------------------!
NL%IPRINTPOLYS = 0
NL%NPVARS = 1
NL%PRINTVARS = 'AVG_PCPG','AVG_CAN_TEMP','AVG_VAPOR_AC','AVG_CAN_SHV'
NL%PFMTSTR = 'f10.8','f5.1','f7.2','f9.5'
NL%IPMIN = 1
NL%IPMAX = 60
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! Variables that control the meteorological forcing. !
! !
! IMETTYPE -- Format of the meteorological dataset !
! 0. ASCII (deprecated) !
! 1. HDF5 !
! ISHUFFLE -- How to choose an year outside the meterorological data range (see !
! METCYC1 and METCYCF). !
! 0. Sequentially cycle over years !
! 1. Randomly pick the years, using the same sequence. This has worked !
! with gfortran running in Mac OS X system, but it acts like option 2 !
! when running ifort. !
! 2. Randomly pick the years, choosing a different sequence each time !
! the model is run. !
! IMETCYC1 -- First year with meteorological information !
! IMETCYCF -- Last year with meteorological information !
! IMETAVG -- How the input radiation was originally averaged. You must tell this !
! because ED-2.1 can make a interpolation accounting for the cosine of !
! zenith angle. !
! -1. I don't know, use linear interpolation. !
! 0. No average, the values are instantaneous !
! 1. Averages ending at the reference time !
! 2. Averages beginning at the reference time !
! 3. Averages centred at the reference time !
! IMETRAD -- What should the model do with the input short wave radiation? !
! 0. Nothing, use it as is. !
! 1. Add them together, then use the SiB method to break radiation down !
! into the four components (PAR direct, PAR diffuse, NIR direct, !
! NIR diffuse). !
! 2. Add then together, then use the method by Weiss and Norman (1985) !
! to break radiation down to the four components. !
! 3. Gloomy -- All radiation goes to diffuse. !
! 4. Sesame street -- all radiation goes to direct, except at night. !
! INITIAL_CO2 -- Initial value for CO2 in case no CO2 is provided at the meteorological !
! driver dataset [Units: µmol/mol] !
!---------------------------------------------------------------------------------------!
NL%IMETTYPE = 1
NL%ISHUFFLE = 0
NL%METCYC1 = 2000
NL%METCYCF = 2008
NL%IMETAVG = 0
NL%IMETRAD = 2
NL%INITIAL_CO2 = 292.975
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! The following variables control the phenology prescribed from observations: !
! !
! IPHENYS1 -- First year for spring phenology !
! IPHENYSF -- Final year for spring phenology !
! IPHENYF1 -- First year for fall/autumn phenology !
! IPHENYFF -- Final year for fall/autumn phenology !
! PHENPATH -- path and prefix of the prescribed phenology data. !
! !
! If the years don't cover the entire simulation period, they will be recycled. !
!---------------------------------------------------------------------------------------!
NL%IPHENYS1 = 1992
NL%IPHENYSF = 2003
NL%IPHENYF1 = 1992
NL%IPHENYFF = 2003
NL%PHENPATH = 'edts_datasets/phenology/phenology'
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! These are some additional configuration files. !
! IEDCNFGF -- XML file containing additional parameter settings. If you don't have !
! one, leave it empty !
! EVENT_FILE -- file containing specific events that must be incorporated into the !
! simulation. !
! PHENPATH -- path and prefix of the prescribed phenology data. !
!---------------------------------------------------------------------------------------!
NL%IEDCNFGF = 'm34_test.xml'
NL%EVENT_FILE = 'myevents.xml'
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! Census variables. This is going to create unique census statuses to cohorts, to !
! better compare the model with census observations. In case you don't intend to !
! compare the model with census data, set up DT_CENSUS to 1., otherwise you may reduce !
! cohort fusion. !
! DT_CENSUS -- Time between census, in months. Currently the maximum is 60 !
! months, to avoid excessive memory allocation. Every time the !
! simulation reaches the census time step, all census tags will be !
! reset. !
! YR1ST_CENSUS -- In which year was the first census conducted? !
! MON1ST_CENSUS -- In which month was the first census conducted? !
! MIN_RECRUIT_DBH -- Minimum DBH that is measured in the census, in cm. !
!---------------------------------------------------------------------------------------!
NL%DT_CENSUS = 12
NL%YR1ST_CENSUS = 2000
NL%MON1ST_CENSUS = 1
NL%MIN_RECRUIT_DBH = 10
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! The following variables are used to control the detailed output for debugging !
! purposes. !
! !
! IDETAILED -- This flag controls the possible detailed outputs, mostly used for !
! debugging purposes. Notice that this doesn't replace the normal debug- !
! ger options, the idea is to provide detailed output to check bad !
! assumptions. The options are additive, and the indices below represent !
! the different types of output: !
! !
! 1 -- Detailed budget (every DTLSM) !
! 2 -- Detailed photosynthesis (every DTLSM) !
! 4 -- Detailed output from the integrator (every HDID) !
! 8 -- Thermodynamic bounds for sanity check (every DTLSM) !
! 16 -- Daily error stats (which variable caused the time step to shrink) !
! 32 -- Allometry parameters, and minimum and maximum sizes !
! (two files, only at the beginning) !
! !
! In case you don't want any detailed output (likely for most runs), set !
! IDETAILED to zero. In case you want to generate multiple outputs, add !
! the number of the sought options: for example, if you want detailed !
! photosynthesis and detailed output from the integrator, set IDETAILED !
! to 6 (2 + 4). Any combination of the above outputs is acceptable, al- !
! though all but the last produce a sheer amount of txt files, in which !
! case you may want to look at variable PATCH_KEEP. It is also a good !
! idea to set IVEGT_DYNAMICS to 0 when using the first five outputs. !
! !
! !
! PATCH_KEEP -- This option will eliminate all patches except one from the initial- !
! isation. This is only used when one of the first five types of !
! detailed output is active, otherwise it will be ignored. Options are: !
! -2. Keep only the patch with the lowest potential LAI !
! -1. Keep only the patch with the highest potential LAI !
! 0. Keep all patches. !
! > 0. Keep the patch with the provided index. In case the index is !
! not valid, the model will crash. !
!---------------------------------------------------------------------------------------!
NL%IDETAILED = 0
NL%PATCH_KEEP = 0
!---------------------------------------------------------------------------------------!

!---------------------------------------------------------------------------------------!
! IOPTINPT -- Optimization configuration. (Currently not used) !
!---------------------------------------------------------------------------------------!
NL%IOPTINPT = ''
!---------------------------------------------------------------------------------------!

$END
!==========================================================================================!
!==========================================================================================!

Running install with the current version causes a problem with disturbance file

Hello,

As I did a pull request and brought my version of ED2, when running install, I got the following error:

disturbance.f90:787.41:

                                if ( include_pft(ipft) == cpatch%pft(1) ) t
                                     1

Error: Operands of comparison operator '==' at (1) are LOGICAL(4)/INTEGER(4)

Before going in to fix this, I wanted to check if this was due to some issues on my end?

Cold Deciduous PFT Growth

I've found some sort of issue with cold deciduous pft growth at Harvard Forest, which may apply to other sites, and which looks like a code problem to me. These PFTs don't grow, at least under my inherited prescribed phenology scheme, so others running with cold-deciduous PFTs probably want to look at a breakdown of basal area by PFT to determine if this is the case for them as well. See the panels below, particularly the basal area plots.

  • Each set of panels is for a pft class
    • the first 9 are for conifers
    • the second 9 are for hardwoods.
  • Each plot has two trajectories;
    • One in which I've changed the allowed hardwood growing season from strictly June to May - Aug.
      • This is not presently a proposed fix, just an experiment.
    • One in which I haven't, meaning hardwoods can only add to BDEAD in June (for lat>0)

Conifers:
pools - co

Hardwoods (Cold Deciduous):
pools - hw

I believe the issue has to do with the phenology flag system. Hardwoods can add to bdead provided the following code snippet is cleared (in structural_growth.f90:plant_structural_allocation):

   !----- Check whether this is late spring... --------------------------------------------!
   late_spring = (lat >= 0.0 .and. current_time%month ==  6) .or.                          &
                 (lat <  0.0 .and. current_time%month == 12) 
   !---------------------------------------------------------------------------------------!


   select case (ibigleaf)
   case (0)
      !------------------------------------------------------------------------------------!
      !      Size and age structure.  Calculate fraction of bstorage going to bdead and    !
      ! reproduction.  First we must make sure that the plant should do something here.  A !
      ! plant should not allocate anything to reproduction or growth if it is not the      !
      ! right time of year (for cold deciduous plants), or if the plants are actively      !
      ! dropping leaves or off allometry.                                                  !
      !------------------------------------------------------------------------------------!
      if ((phenology(ipft) /= 2   .or.  late_spring) .and. phen_status == 0)    then

Here's a plot of phen_status by month, as seen by plant_structural_allocation, for 94,95, and 96.

hf_phenology_stat_by_pft

You can see that phen_status is typically not 0 for hardwoods in June. This is despite elongf being 1.0 as of late May in all the HDF5 output I've seen, which would seem to indicate that the prescribed phenology itself is not the issue. I'll update this when I know why...

Any ideas/commentary appreciated...

Radiative parameters in ED2

We are currently working on running sensitivity analysises and data assimilation on radiative parameters on ED2, Our initial intent was to approach this through XML-files, but since the current mainline version of ED2 calculates the scattering parameters from transmittance and reflectance parameters already in ed_params.f90 file, changing them won't affect the results.

So before we think of taking those values out of the ed_params file and possibly starting to change the interconnections in the model, I wanted to check if that had been done yet in some version of ED2?

-- Toni

Trouble with met files using HDF5/1.8.13 library

We are currently setting up the current version of ED2 to run our server, which has the newest version of HDF5 libraries, version 1.8.13, installed. However, when we try to run ED2 in it, we are running in to an issue with the met files, where it reads the temperature in as NaN. All the input files have been copied over from geo cluster on BU, where they run fine and without this problem, and as far as we can tell, the only difference is the HDF5 version.

Has there been anyone else with similar problems? And if so, are there any suggestions on how to approach this problem?

-- Toni

SMP Release

Hi All,

I put the Shared Memory Parallelism commits on the master. This will allow for the splitting of radiation scattering, photosynthesis and thermodynamics of different patches to different CPU cores.

This has been tested using RK4 and Hybrid integration
This has had limited testing on gridded runs
This has had no testing on coupled runs (but I don't suspect any breakage).

If you don't want to use shared memory, just keep doing what you have done in the past and nothing should change.

If you do want to use it, follow these steps for a single polygon run:

  1. compile code with shared memory directives, if you are using OpenMP, the flag is '-fopenmp'
  2. (optional) increase your stack size. On linux: "ulimit -s unlimited"
  3. set run-time environment variables. If you are using OpenMP, the key variable is OMP_NUM_THREADS. This defines how many shared memory cores will be used. On linux:
    "export OMP_NUM_THREADS=X" where X is the number of cores you wish to use. REMEMBER: These cores must share RAM, so you are limited by the number of cores that are on one node.
  4. Execute the simulation as you would normally.

This release is experimental for the time being. If you have trouble or crashes or poor reproducability of previous work, revert to commit 2a5d68e

ie:

git checkout 2a5d68e

NetCDF4 causing issues with RAPP code

The NCEP Reanalysis people have switched their file formats from NetCDF3 to NetCDF4 (http://www.esrl.noaa.gov/psd/data/gridded/netcdf4.html). One of the advantages:
"It also has the advantage that we will not need to pack the data using a scale and offset and users will not need to unpack data."
Which causes trouble with the unpacking part of the code: I get the fatal error that a variable is not a short integer (NF90_SHORT). Indeed, as an example, "ncdump -h air.sig995.1980.nc" tells me that air is a float.

Now - can I just leave out the rescaling in mod_ncdf_globio (lines 1350 to 1358), and of course change line 1333 (xtype /= NF90_SHORT) so it does not throw the fatal error, or are there other places where this could be an issue...?

How to process only specific NCEP variables

I would like to use only one variable out of the NCEP reanalysis and thus I am wondering if there is a way to use RAPP to process only a subset of variables without downloading the whole set.

In my specific case I need to convert specific humidity so I would like to avoid downloading all the other data. How can I do this?

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.