dssat / dssat-csm-os Goto Github PK
View Code? Open in Web Editor NEWDSSAT Cropping System Model
License: BSD 3-Clause "New" or "Revised" License
DSSAT Cropping System Model
License: BSD 3-Clause "New" or "Revised" License
Excuse me, does anyone know how to simulate the effect of soil stress on rice yield?please
Please add a nix shell environmment with a fortran compiler.
# a native OSX environment with cmake but not a fortran compiler
⋊> ~/d/s/c/dssat-csm-os on develop ⨯ mkdir build
⋊> ~/d/s/c/dssat-csm-os on develop ⨯ cd build
⋊> ~/d/s/c/d/build on develop ⨯ cmake ..
-- The Fortran compiler identification is unknown
CMake Error at CMakeLists.txt:16 (PROJECT):
No CMAKE_Fortran_COMPILER could be found.
Tell CMake where to find the compiler by setting either the environment
variable "FC" or the CMake cache entry CMAKE_Fortran_COMPILER to the full
path to the compiler, or to the compiler name if it is in the PATH.
-- Configuring incomplete, errors occurred!
See also "/.../build/CMakeFiles/CMakeOutput.log".
See also "/.../build/CMakeFiles/CMakeError.log".
# a nix-shell environment with cmake and gfortran
⋊> ~/d/s/c/dssat-csm-os on develop ⨯ nix-shell
[nix-shell:~/dev/src/crop-model/dssat-csm-os]$ mkdir build
[nix-shell:~/dev/src/crop-model/dssat-csm-os]$ cd build
[nix-shell:~/dev/src/crop-model/dssat-csm-os/build]$ cmake ..
-- The Fortran compiler identification is GNU 7.3.0
-- Checking whether Fortran compiler has -isysroot
-- Checking whether Fortran compiler has -isysroot - yes
-- Checking whether Fortran compiler supports OSX deployment target flag
-- Checking whether Fortran compiler supports OSX deployment target flag - yes
-- Check for working Fortran compiler: /nix/store/0xc8v7pvb2marnymliad8brbch522szz-gfortran-wrapper-7.3.0/bin/gfortran
-- Check for working Fortran compiler: /nix/store/0xc8v7pvb2marnymliad8brbch522szz-gfortran-wrapper-7.3.0/bin/gfortran -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /nix/store/0xc8v7pvb2marnymliad8brbch522szz-gfortran-wrapper-7.3.0/bin/gfortran supports Fortran 90
-- Checking whether /nix/store/0xc8v7pvb2marnymliad8brbch522szz-gfortran-wrapper-7.3.0/bin/gfortran supports Fortran 90 -- yes
-- MAJOR: 4 MINOR: 7 MODEL: 5 BUILD: 14 COMMIT: f515732
-- BRANCH: develop
-- COMMIT: f515732544fb8f8c54ce9f863fe4871044de8a2c
-- CMAKE_BUILD_TYPE not given, defaulting to DEBUG
-- Flags
FFLAGS -fd-lines-as-comments -fbounds-check -ffixed-line-length-none -ffree-line-length-none -finit-character=32 -cpp -ffpe-trap=invalid,zero,overflow -mmacosx-version-min=10.10.0
RELEASE -O3 -DNDEBUG -O3 -funroll-loops -finline-functions
DEBUG -g -Og -Wall -fbacktrace -fcheck=bounds
LINKER
-- Build Info
BUILD TYPE DEBUG
VERSION 4.7.5.14
I. PREFIX /var/empty/local
Executable dscsm047
-- Configuring done
-- Generating done
-- Build files have been written to: /.../build
Hi, I am trying to do some simulation about paddy field with methane model recently. I see several parameters that may need calibration in MERES model papers(Using a crop/soil simulation model and GIS techniques to assess methane emissions from rice fields in Asia. II. Model validation and sensitivity analysis), two of which I didn't find the location in the code annotations.(the root death constant (δr), the specific root exudation rate (εr),. Can you help me locate it?
Could simplify the output and only bring over the cumulative values. These are the most important. Do not bring over all the soil layer data. We will probably remove these from the standard output.
When running DSSAT-CSM-CROPSIM-CERES-Wheat in seasonal mode, the XHLAI value is not reset when DYNAMIC .EQ. SEASINIT
:
Lines 332 to 347 in e4470f7
When SEASINIT matches PDATE, then this is not a big problem because the DYNAMIC .EQ. INTEGR
will reset XHLAI to XLAI soon after simulation starts. However, if final XHLAI from a previous run is not small and SEASINIT is substantially before PDATE (e.g. 3 month spinup), then ET will be simulated much higher than it should be. I believe that this will be a potential problem for any model that (unlike CROPGRO, N-wheat, etc) does not directly calculate XHLAI. One solution that should work would be to modify the code for those models a la:
IF (DYNAMIC .EQ. SEASINIT) THEN
KTRANS = KEP
KSEVAP = KEP
XHLAI = XLAI
ELSEIF (DYNAMIC .EQ. INTEGR) THEN
XHLAI = XLAI
ENDIF
This way the XHLAI gets reset to whatever the pre-planting value for that crop should be. Presumably the value would usually (always?) be 0 and we could code it up with that assumption, but allowing each model to set this seems like a more flexible option. @chporter @GerritHoogenboom, any thoughts?
Implement cultivar (and eco and spe) version numbers with code checking for the correct version.
Priority: rice and NWheat
In addition to the helpful pages already published on the DSSAT site, please consider using sphinx for making a users guide for this project. This could be published with readthedocs.io or self-hosted at https://dssat.net/users-guide.
Here are some examples of users guides compiled this way.
https://docs.haskellstack.org
https://www.haskell.org/cabal/users-guide
https://flare-timing.readthedocs.io
The GET functions in the CSM are trying to get a value for PMFRAC, but they cannot find this value and throw a WARNING message basically for everyday during the simulation creating a spam in the WARNING.OUT file. Also, there is a need to check why PMFRAC is being set to zero and if this is the correct behavior and it is not going to affect anything else in the model.
Below it is a image of an WARNING.OUT file with the warning message:
Help file still has old citations under "How to cite". There might be other issues, too.
Hello, I was able to install CMAKE and gfortran on my Windows 10 system. I downloaded the latest dssat source code using the git url.
Using the Cmake GUI, I indicated the location of the DSSAT source code and a separate build directory as shown in the screenshot:
I run the "Configure" followed by the "Generate" commands, but the DSSAT executable is not produced. I'm not sure what else to do to successfully compile DSSAT on my system.
Hi @chporter , @GerritHoogenboom and @frostbytten ,
We are trying to do a test run of DSSAT with some representative inputs in order to make sure that our program analysis pipeline produces outputs that are faithful to the original code.
Would it be possible to get an example dataset and invocation of the dscsm047
executable to see if we can generate the expected outputs? I managed to get the following output:
RUN TRT FLO MAT TOPWT HARWT RAIN TIRR CET PESW TNUP TNLF TSON TSOC
dap dap kg/ha kg/ha mm mm mm mm kg/ha kg/ha kg/ha t/ha
1 SB 1 -99 -99 -99 -99 -99 -99 -99 -99 -99 -99 -99 0
2 SB 2 -99 -99 -99 -99 -99 -99 -99 -99 -99 -99 -99 0
3 SB 3 -99 -99 -99 -99 -99 -99 -99 -99 -99 -99 -99 0
4 SB 4 -99 -99 -99 -99 -99 -99 -99 -99 -99 -99 -99 0
By copying the following files (from the files sent by @chporter by email on 10/30/2018 from running the ASCE and PET options for a 1978 soybean experiment in Gainesville, FL) to the Data
directory:
DSSBatch.v47
FERCH047.SDA
SBGRO047.CUL
SBGRO047.ECO
SBGRO047.SPE
SOIL.SOL
UFGA7801.SBX
dscsm047
and running the following command:
./dscsm047 B DSSBatch.v47
While the program runs to completion, the outputs seem funky, so I am fairly sure I am doing something wrong over here. We would be grateful for any help you could provide on this.
I'm tagging @skdebray , @cl4yton , and @pauldhein to keep them in the loop.
Thanks!
Related to issue #32
SC_rm_file.f90
and change lines 18 and 50 which currently have:
inquire(file=io, exist=file_exists)
to
inquire(unit=io, exist=file_exists)
as the "file" tag can only accept character input, but the unit tag can accept integer input, and io is declared to be an integer.
After making that change the compilation successfully completed and I was able to produce the dssat executable.
Hi, @chporter I have looked at the solved issues. I found one similar solved issue [#7] @adarshp which is also happening to me when I try to simulate Filex. This error is happening to generated filex, not for the default filex. I am attaching the following error, could you please help me to solve it?
**Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.
Backtrace for this error:
#0 0x90a70f in ???
#1 0x86692f in pgleaf_
at /tmp/dssat-csm-os/SPAM/ETPHR.for:621
#2 0x8675c4 in canopg_
at /tmp/dssat-csm-os/SPAM/ETPHR.for:374
#3 0x868340 in etphr_
at /tmp/dssat-csm-os/SPAM/ETPHR.for:218
#4 0x863064 in etphot_
at /tmp/dssat-csm-os/SPAM/ETPHOT.for:569
#5 0x86f581 in spam_
at /tmp/dssat-csm-os/SPAM/SPAM.for:435
#6 0x44cf8a in land_
at /tmp/dssat-csm-os/CSM_Main/LAND.for:338
#7 0x44b6c9 in csm
at /tmp/dssat-csm-os/CSM_Main/CSM.for:512
#8 0x44c6db in main
at /tmp/dssat-csm-os/CSM_Main/CSM.for:82**
The existing code allows DUL to increase above SAT when DUL is adjusted for SOM. Although DUL and LL are adjusted, there is no concomitant adjustment for SAT:
dssat-csm-os/Soil/SoilUtilities/SOILDYN.for
Lines 1203 to 1215 in 37d00a5
As a result, DUL_SOM can be higher than SAT under some conditions. I think we have a couple of options:
As it is, if DUL does become higher than SAT and SW happens to be equal to SAT then we can get floating point exceptions in OXLAYER (and possibly other places?):
dssat-csm-os/Soil/Inorganic_N/OXLAYER.for
Lines 201 to 203 in 37d00a5
Environmental modifications need to be set with each rotation. We should be able to set a CO2 value, for example, in the first rotation and have it stay for all rotations.
You can force it by setting the EM level for all rotations.
There are several lines in for_ch2oref.for where there are no checks to avoid divide by zero:
C-----------------------------------------------------------------------
C C Status is current CH2O concentration as a proportion of Max CH2O capacity
C-----------------------------------------------------------------------
CSTATUS = (WCRLF + WCRRT + WCRSR + WCRST -
& (SLDOT * WCRLF/RTWT - LFSCMOB) - (SSDOT * WCRST/STMWT
& - STSCMOB) -
& (SRDOT * WCRRT/RTWT - RTSCMOB) - (SSRDOT * WCRSR/STRWT
& - SRSCMOB)) / (LFMCCAP + STMCCAP + RTMCCAP + SRMCCAP)
C-----------------------------------------------------------------------
C CH2O REFILL capacity is the Max CH2O capacity described above minus
C today's CH2O content.
C-----------------------------------------------------------------------
LFCCAP = LFMCCAP - WCRLF - (SLDOT * WCRLF/WTLF - LFSCMOB)
IF (LFCCAP .LE. 0.0) LFCCAP = 0.0
STCCAP = STMCCAP - WCRST - (SSDOT * WCRST/STMWT - STSCMOB)
IF (STCCAP .LE. 0.0) STCCAP = 0.0
RTCCAP = RTMCCAP - WCRRT - (SRDOT * WCRRT/RTWT - RTSCMOB)
IF (RTCCAP .LE. 0.0) RTCCAP = 0.0
SRCCAP = SRMCCAP - WCRSR - (SSRDOT * WCRSR/STRWT - SRSCMOB)
IF (SRCCAP .LE. 0.0) SRCCAP = 0.0
There are commits that look like they would correspond to release tags for 4.7.5.32-4.7.5.41, but no tags for those commits. Is that intentional? If not, could they be added?
Thanks!
The path for OilCrop-Sunflower in CMakelists.txt lacks a capital "C":
Lines 507 to 516 in 37d00a5
This is a problem for compiling on Linux (and possibly on Mac?). I'll submit a pull request in just a sec.
Currently the forage model has a problem with mass balance of root CH2O and N. One contributing issue is related to SRNDOT being calculated twice and SRDOT not being updated after the second calculation.
SRNDOT is first calculated in for_senmob.for
:
dssat-csm-os/Plant/FORAGE/for_senmob.for
Line 581 in a2db1cc
dssat-csm-os/Plant/FORAGE/for_senmob.for
Line 582 in a2db1cc
dssat-csm-os/Plant/FORAGE/for_roots.for
Line 165 in ec86523
for_grow.for
where the code for root dry matter senescence uses SRDOT:dssat-csm-os/Plant/FORAGE/for_grow.for
Lines 914 to 915 in ec86523
dssat-csm-os/Plant/FORAGE/for_grow.for
Lines 1238 to 1249 in ec86523
My reading of the code indicates that the SRNDOT, SRMDOT, and SRDOT calculations should be handled in for_senmob.for
only.
Commenting out the line in for_roots.for
does seem to resolve the CH2O balance issues, but another N mass imbalance is still present and needs to be tracked back. I'm getting more than 100% root N concentration under some circumstances.
The calculation of CMINESR
is different from the calculation of CMINERT
in FOR_SENMOB()
:
dssat-csm-os/Plant/FORAGE/for_senmob.for
Lines 939 to 944 in e25b199
Note that the calculation for CMINERT
contains PPMFAC
while the calculation for CMINESR
does not. PPMFAC
is the factor that reduces mobilization of carbohydrate/nitrogen reserves due to dormancy. I wonder if it should be the other way around.
It seems to me that dormancy should affect remobilization from the storage organ but not the other tissues. Alternatively, I suppose it might be okay to have it affect root and storage. However, it makes no sense to me that it would affect only root.
Scratch that.
The calculation for CMOBSR
already has PPMFAC in it:
dssat-csm-os/Plant/FORAGE/for_senmob.for
Lines 866 to 867 in e25b199
I guess it's not wrong. Just confusing. I think we should consider moving PPMFAC down to the place where CMINESR
is calculated.
Possible crop statuses:
1 - crop harvested at maturity
2 - crop harvested on reported date
11 - failure to plant (automatic planting)
12 - failure to germinate
21 - crop mature due to slow grain filling
31 - crop died due to heat stress
32 - crop died due to cold stress
33 - crop died due to deficit water stress
34 - crop died due to excess water stress
51 - crop died due to pest damage
In the Structure of the code section there's a tree showing, among other things, where to find the Documentation
folder. The Data section mentions documentation too. Is this folder missing in the source repository or is it a build output?
.
└── Data
├── Documentation
Can we change the variables N and P to Nel (or NIT) and Pel (PHOS)? This would require many changes to the code but will allow users to use the single character N, P for loop indices, etc.
but there is in the MgmtEvent.OUT
Fix.
Documenting another problem of divide by 0 in the forage model. The issue is in for_dormancy.for:
dssat-csm-os/Plant/FORAGE/for_dormancy.for
Lines 348 to 356 in eff9511
I will fix it and submit a pull request.
FIND_IN_FILE()
is generating a Fortran runtime error when the specified crop code is not found in DETAIL.CDE. I need to investigate further to isolate the problem.
Add code to allow NWheat (and teff) to simulate potential production when ISWWAT = "N" and ISWNIT = "N"
For some environments, wheat keeps growing until it runs out of weather. We should put a maximum limit on all stages.
This issues was opened because of an issue on the SEAS (*EXP.DETAILS: SEAS1214MZ 2012-2014 SERIDA EXPERIMENT ASTURIAS, SPAIN) from Dr. Jose and Dr. Boote.
*** Some details:**
Exe: dscsm048.exe (v4.8.0.27)
Install: DSSAT Installation 05 01 2022.zip
The error happens when:
MZCER048.ECO is not in the same folder as the FileX
Note we still have the MZCER048.ECO from the Genotype folder
There is no WARNING.OUT or ERROR.OUT related to this problem.
The model simply does not run all the treatments.
Check if this happens for all crops/models.
Check if other Maize experiments show the same problem.
Something is linked with the ECOTYPE file and it is not showing ERROR when it should.
This is a system issue.
When running the ALL.v48 file, the simulations stop after SXPG6801.SCX.
When running just sugarcane, all is OK.
When going from SXPG6801.SCX to AUTA8101.SUX, all is OK, so it seems to be the UFBG files. However, these run OK by themselves.
Just noting this here so we don't forget.
When something in the model fails prior to planting, the planting date is set to 9999999 (or something like that) in Summary.OUT. However the harvest date is set to the date of failure. This causes problems when we analyze massive outputs from pythia. We nee to change the planting AND harvest dates written to Summary.OUT
If more than one stage occurs on a day, only the last one is printed in MgmtEvents.OUT.
OPVIEW.for line 251.
In OPVIEW:
!Store current Stage, STGDOY and STNAME
CALL PUT('PLANT','iSTAGE', I)
CALL PUT('PLANT','iSTGDOY', STGDOY(I))
CALL PUT('PLANT','iSTNAME', STNAME(I))
In MgmtOps.for:
! Retrieve current Stage, STGDOY and STNAME
CALL GET('PLANT','iSTAGE', iSTAGE)
CALL GET('PLANT','iSTGDOY', iSTGDOY)
CALL GET('PLANT','iSTNAME', iSTNAME)
The issue is that one value is sent at at time. Only the last value "PUT" will be retrieved with "GET". Need to send the entire array if we want to print more than one. Or send the whole array STNAME and STGDOY thru the argument lists. Or create a module?
Should temperature sensitivity analysis (environmental modification) for TMAX and TMIN include a change to the TAV used in soil temperature calculations? This would be important for soil organic matter, automatic planting, emergence, plant N and soil N processes. We should at least look at the impact.
Run the attached batch file (DTSP8502.RIX, trt 1; UHIH1702.QUX, trt 8; then DTSP8502.RIX, trt 1 again).
Custom_v48.txt
The simulation gives different results for rice simulation the 2nd time.
I haven't had time to fully investigate, but some N variables (total inorganic N, N uptake, nitrification) are different near the end of the season. That's one clue, but more variables need to be investigated before we can draw conclusions. I'm guessing it's a plant module intitialization issue that only showed up after Quinoa genotype files were updated. (!).
Not a CSM issue, but since we don't have a repository for XBuild, I'll store this here.
Cultivar selection in XBuild is based on name of cultivar, not Crop-Cultivar ID combination. The cultivar name may be shared among different crops, e.g., "Manitou" which is the name of a drybean cultivar and a wheat cultivar. When "Manitou" is selected as a wheat cultivar, it comes with an ID of IB0012, which is the cultivar ID of the drybean "Manitou" cultivar instead of IB1500 which is the wheat "Manitou" cultivar. The simulation fails because there is no wheat cultivar with ID IB0012. (Worse yet, if there was a wheat cultivar with IB0012, the model would use that.)
In XBuild, the cultivar should be identified by crop and cultivar ID, not by cultivar name.
this is a test. this is only a test. @GerritHoogenboom @chporter
Transferring this issue from the private repo. I'm not sure that it's been resolved yet. Have we differentiated between DOY and DAP in all FileAs?
from @palderman :
I'm going through some final (I hope) checking for the DSSAT R package I've put together and about to start writing up. Anyway, I've been noticing that a lot of the A files (files A?) that are in the DSSAT CSM repo have only 3-digit values in the columns for MDAT and ADAT. For example:
Barley/IEBR8201.BAA
Barley/MTBO7701.BAA
Canola/USON0801.CNA
Canola/USOT0801.CNA
I'm thinking that people have mislabeled those columns (should be ADAP or MDAP?), but I wanted to check to be sure I haven't missed something.
Some additional examples:
Chickpea/ITBW9205.CHA
Chickpea/ITBW9306.CHA
For these examples, it seems that the ADAT values might be simply day of year? In any case, there seems to be some problem.
from @GerritHoogenboom
Yes, that's correct. Currently FileA is read by the model only and there are smarts to associate the Year with the DOY value.
We generated a slightly imperfect 4-digit weather file using the AgMIP DSSAT translator and got some unexpected results. The format of the file did not have the 2-spaces between the "@" and "DATE" on the header line (i.e., @DATE SRAD
instead of @ DATE SRAD
). The model ran, but values of SRAD were interpreted incorrectly and the model results were very bad. But there was no error message.
Actually, the more I think about it, the model is behaving correctly because it is trying to right-justify data under the headers. Let's review this at a mini-sprint, but maybe we do nothing.
I'm getting floating point errors with the forage model related to the fact that RADSH
is negative due to ADDF
being negative in CANABS() in ETPHOT.for. When I uncomment the check for ADDF < 0.0
(see below), the problem goes away. The issue seems to be limited to situations with very low LAI.
Is there a reason why the checks for negative numbers are commented out in CANABS() in ETPHOT.for? Is there any problem with allowing ADDF
, ADDFSL
, etc to be set to zero when the original calculation is negative? See here:
Lines 1793 to 1800 in a20a2b5
Lines 1814 to 1827 in a20a2b5
Lines 1862 to 1869 in a20a2b5
Lines 1883 to 1890 in a20a2b5
When running a batch file from a directory other than the location of the FileX, the MOW file is not found. Need to add a path to data directory.
Example - I'm running CSM from the CropTest WorkA directory. Forage crops with a MOW file all fail.
The CMakeLists.txt specifies the creation of the file conditionally:
[...]
IF(WIN32)
SET(OSDefinitions "Utilities/OSDefsWINDOWS.for")
add_definitions(-DWIN32=1})
ELSE()
[...]
configure_file(
"${PROJECT_SOURCE_DIR}/Utilities/run_dssat.in"
"${PROJECT_SOURCE_DIR}/Utilities/run_dssat"
)
ENDIF(WIN32)
[...]
but mentions it unconditionally when specifying what to install:
[...]
install(FILES Utilities/run_dssat DESTINATION .
PERMISSIONS OWNER_READ OWNER_WRITE OWNER_EXECUTE GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE
)
[...]
This caused the Visual Studio 2019 build of the install-project to fail on the system of @GangaRamMaharjan.
The Visual Studio project files were generated with the CMake 3.18.1 GUI.
Also wrapping the install code with IF(WIN32)
and ENDIF(WIN32)
fixed the problem, IIRC.
Recently, I used the default rice example to simulate that ch4 is not emitted, and n2o and co2 are normal. Is it necessary to set something or not support rice
This issue happened when Sequence mode run without .CLI file, the model tried to open the .WTH file. The IPEXP subroutine has a section that build the weather file name based on the weather station on the FileX. However, there is a conflict that is causing error when running WGEN subroutines.
Another subroutine could be created to split each run mode and type of weather file to avoid conflict between different types of runs for the CSM.
The code below indicates what need to be checked:
! Generated weather data files
IF (MEWTH .EQ. 'G') THEN
IF (WSTA1(4:4) .EQ. BLANK) THEN
IF (YEAR .LT. 2000) THEN
YR = YEAR - 1900
ELSE IF (YEAR .LT. 3000) THEN
YR = YEAR - 2000
ENDIF
WRITE (FILEWG(1:12),75) WSTA,YR,'01.WTG'
ELSE
WRITE (FILEWG(1:12),76) WSTA,WSTA1,'.WTG'
ENDIF
PROCODG = 'WGD'
ENDIF
! Interactively generated weather
IF (MEWTH .EQ. 'S' .OR. MEWTH .EQ. 'W') THEN
WRITE (FILEWC(1:12),77) WSTA,'.CLI '
PROCODC = 'CLD'
ENDIF
! Measured weather data
IF (MEWTH .EQ. 'M' .OR. RNMODE .EQ. 'Y') THEN
IF (WSTA1(4:4) .EQ. BLANK) THEN
IF (YEAR .LT. 2000) THEN
YR = YEAR - 1900
ELSE IF (YEAR .LT. 3000) THEN
YR = YEAR - 2000
ENDIF
WRITE (FILEW(1:12),75) WSTA,YR,'01.WTH'
ELSE
WRITE(FILEW(1:12),76) WSTA,WSTA1,'.WTH'
ENDIF
PROCODW = 'WED'
ENDIF
IF (INDEX('GSWM',RNMODE) .LT. 0) THEN
CALL ERROR (ERRKEY,22,FILEX,LINEXP)
ENDIF
! Check for existing FILEW, FILEWC, and FILEWG
DO I = 1, 3
SELECT CASE (I)
CASE (1)
IF (MEWTH .EQ. 'M' .OR. RNMODE .EQ. 'Y') THEN
FILE_CHECK = FILEW
PROCOD = PROCODW
ELSE
CYCLE
ENDIF
CASE (2)
IF (MEWTH .EQ. 'G') THEN
FILE_CHECK = FILEWG
PROCOD = PROCODG
ELSE
CYCLE
ENDIF
CASE (3)
IF (MEWTH .EQ. 'S' .OR. MEWTH .EQ. 'W') THEN
FILE_CHECK = FILEWC
PROCOD = PROCODC
ELSE
CYCLE
ENDIF
CASE DEFAULT; CYCLE
END SELECT
Long pathnames fail in CSCER etc. code. When path to executable is long, model fails. See thread on private repo here: https://github.com/DSSAT/dssat-csm/issues/255
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.