From 207c3b1fe0d9981d4ddca50f8867a56cb2a28847 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zolt=C3=A1n=20BARCZA?= Date: Tue, 10 Dec 2019 11:21:53 +0100 Subject: [PATCH] updates --- README.org | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/README.org b/README.org index a3a9127..b2391d7 100644 --- a/README.org +++ b/README.org @@ -59,17 +59,16 @@ Once the copyMusoExampleTo command is finished, the model input dataset and the In this example the C:\model directory will contain the following files: - muso.exe - this is the Biome-BGCMuSo 6.0 model executable for Windows (version might change in the future) -- muso - this is the model executable for Linux - cygwin1.dll - a so-called DLL file that supports the model execution under Windows -- c3grass.epc - ecophysiological constants input file for the model (C3 grass in this case) -- maize.epc - another ecophysiological constants input file (C4 maize in this case) +- c3grass_muso6.epc - ecophysiological constants input file for the model (C3 grass in this case) - n.ini - initialization file for the model, normal mode (INI file controls the entire simulation) -- grass_normal.ini - another initialization file for the model, for the C3 grass simulation - s.ini - initialization file for the model spinup (also known as self-initialization or equilibrium run) -- parameters.csv - a simple text file to support parameter sweep and sensitivity analysis (see below) -- hhs_1961-2014.mtc43 - meteorology input file; in this example this file is used for spinup simulation -- hhs_2013-2016.mtc43 - meteorology input file for the normal simulation -- CO2_from1961.txt - CO_{2} file for the transient simulation +- hhs.soi - soil file for the Hegyhátsál simulation +- hhs.mtc43 - meteorology input file +- hhs.mgm - management definition file for the simulation +- hhs.mow - ancillary management file for mowing +- Ndep.txt - Nitrogen deposition file for the simulation +- CO2.txt - CO_{2} file for the simulation In the followings we will demonstrate the usability of RBBGCMuso with the hhs example dataset. If you have your own model input data set, you might need to change the commands accordingly. @@ -102,15 +101,15 @@ In order to run the model as it is provided simply use the following command in runMuso(skipSpinup = FALSE) #+END_SRC -Note that by default runMuso skips the spinup simulation (in order to speed up the model execution), but in our case we do not yet have the result of the spinup run (the so-called endpoint file), so spinup simulation is obligatory. This is performed with the skipSpinup=FALSE parameter. Note that according to the naming convention described above the model will use s.ini and n.ini for spinup and normal phase, repsectively (this can be changed with the parameters of runMuso). It means that the 3rd ini file is not used in this case (grass_normal.ini). As n.ini represents a maize simulation, the results will provide simulation data on C4 maize monoculture with predefined management defined by the n.ini file. +Note that by default runMuso skips the spinup simulation (in order to speed up the model execution), but in our case we do not yet have the result of the spinup run (the so-called endpoint file), so spinup simulation is obligatory. This is performed with the skipSpinup=FALSE parameter. Note that according to the naming convention described above the model will use s.ini and n.ini for spinup and normal phase, repsectively (this can be changed with the parameters of runMuso). As n.ini represents a grass simulation, the results will provide simulation data on C3 grass ecosystem with management defined by the n.ini file. If the simulation is successful, the results can be found in the C:\model directory. In our example two files were created with .log extension that contain some information about the spinup and the normal phase. The hhs.endpoint file is the result of the spinup (and optional transient) run, and can be considered as initial conditions for the normal run. (Here we have to note that now runMuso can be called without the skipSpinup parameter which means that the simulation will be restricted to the normal phase only.) The results of the simulation (carbon fluxes, state variables, whatever was set by the user in the DAILY_OUTPUT block of the normal INI file) are available in the file hegyhatsal.dayout. Note that annual output was not requested in this case. Also note that in the hhs example file set binary daily output is created and further processed by RBBGCMuso. One of the most attractive features of RBBGCMuso is that the model output is handled by the package which means that it will be directly available for the user as a variable for further processing in R. *** Visualization of the model output -Once the simulation is completed (hopefully without errors), we can visualize the results. Biome-BGCMuSo provides large flexibility on model output selection, which means that the results will depend on the settings of the user in the normal INI file (DAILY_OUTPUT block). In our hhs example 39 variables are calculated in daily resolution. As the model is run for 4 years by the normal INI file, each output variable will be available for 4x365 days (note the handling of leap years in the Biome-BGCMuSo User's Guide). +Once the simulation is completed (hopefully without errors), we can visualize the results. Biome-BGCMuSo provides large flexibility on model output selection, which means that the results will depend on the settings of the user in the normal INI file (DAILY_OUTPUT block). In our hhs example 39 variables are calculated in daily resolution. As the model is run for 9 years by the normal INI file, each output variable will be available for 9x365 days (note the handling of leap years in the Biome-BGCMuSo User's Guide). -Assume that we would like to visualize Gross Primary Production (GPP) for one simulation year (this is the 26th variable in the n.ini file). This can be achieved by the following commands. First we re-run the normal phase and redirect the output to the R variable called 'results': +Assume that we would like to visualize Gross Primary Production (GPP) for one simulation year (this is the 2nd variable in the n.ini file). This can be achieved by the following commands. First we re-run the normal phase and redirect the output to the R variable called 'results': #+BEGIN_SRC R :eval no results<-runMuso() @@ -153,12 +152,12 @@ Assume that we would like to dig a bit deeper with the model and understand the musoQuickEffect(calibrationPar = 13, startVal = 0, endVal = 9, nSteps = 5, outVar = 3009) #+END_SRC -This command selects the 25th line in the ecophysiological constants (EPC) file (this is base temperature), then it starts to replace the original value from 0 to 9 in 5 consecutive steps. In this example GPP is selected (variable number 3009, which is the 26th variable), so the effect of varying base temperature on GPP is calculated using 5 simulations. The result is a spectacular plot where color coding is used distinguish the parameter values. +This command selects the 13th line in the ecophysiological constants (EPC) file (this is base temperature), then it starts to replace the original value from 0 to 9 in 5 consecutive steps. In this example GPP is selected (variable number 3009, which is the 2nd variable), so the effect of varying base temperature on GPP is calculated using 5 simulations. The result is a spectacular plot where color coding is used distinguish the parameter values. At present musoQuickEffect is not usable for the allocation parameters due to restrictions of the allocation fractions. *** Study the effect of ecophysiological parameters using paramSweep -The paramSweep function is the extension of the musoQuickEffect. It can test the effect of the multiple selected parameters on the model results in once. The result of the paramSweep function is a single HTML file with embedded images. paramSweep needs a csv file called parameters.csv which defines the parameters of interest and the corresponding parameter intervals. In case of the hhs sample dataset there is an example parameters/csv file (please open it and check). The structure of the parameters.csv file is simple. First, parameter name is needed (it can be anything but should refer to the parameter), then the line number of the EPC file is provided, then the possible minimum and maximum value of the parameter is given. Note that there is a tricky part in the parameters.csv as the parameter selection is not straightforward in case of multiple columns (see the end of the EPC file). The logic is that fractinal part of a number is used to select the appropriate parameter from multiple columns. In the provided example "emergence,170.61,0,1000" means that in the 170th line of the EPC file there are 7 columns (numbering starts from 0, so it is 6), and we would like to adjust the 2nd column (marked by 1), which ends up with 170.61. 0,1000 means that sweep starts at 0 and ends with 1000. Invoke the paramSweep with simply issuing this command: +The paramSweep function is the extension of the musoQuickEffect. It can test the effect of the multiple selected parameters on the model results in once. The result of the paramSweep function is a single HTML file with embedded images. paramSweep needs a csv file called parameters.csv which defines the parameters of interest and the corresponding parameter intervals. In case of the hhs sample dataset there is an example parameters/csv file (please open it and check). The structure of the parameters.csv file is simple. First, parameter name is needed (it can be anything but should refer to the parameter), then the line number of the EPC file is provided, then the possible minimum and maximum value of the parameter is given. Note that there is a tricky part in the parameters.csv as the parameter selection is not straightforward in case of multiple columns (see the end of the EPC file). The logic is that fractinal part of a number is used to select the appropriate parameter from multiple columns. In the provided example "emergence,127.61,0,1000" means that in the 127th line of the EPC file there are 7 columns (numbering starts from 0, so it is 6), and we would like to adjust the 2nd column (marked by 1), which ends up with 127.61. 0,1000 means that sweep starts at 0 and ends with 1000. Invoke the paramSweep with simply issuing this command: #+BEGIN_SRC R :eval no paramSweep()