USDAForestService / ForestVegetationSimulator

Forest Vegetation Simulation (FVS) - Growth and Yield Modeling software
Other
41 stars 26 forks source link

Planting in cycle 0 throws runtime error #29

Closed WY-CGhilardi closed 1 year ago

WY-CGhilardi commented 1 year ago

Version Info: RV:20230106.1 on windows. Installed from the variant installer executable

I originally came across this behavior from a typo, but though the error could be handled better. When using a plant record with a cycle of 0, we return a FORTRAN runtime error.

Using the following .key file, ran with FVSsn.exe --keywordfile= blahh.key

NOTREES
SETSITE           0                             LP       75
NUMCYCLE        3
SCREEN

ESTAB
!throws stacktrace      
PLANT              PARMS(0,LP,385, 85, 1, 0.75, 0)

!uncomment for working version
!PLANT              PARMS(1,LP,385, 85, 1, 0.75, 0)
END

COMMENT
COLUMNS  10        20        30        40        50        60        70        80
....:....|....:....|....:....|....:....|....:....|....:....|....:....|....:....|
END

!OUTPUT TREELISTS
TREELIST           0                   1                   1

DataBase
DSNOut
backtrace_test.db
SUMMARY
TREELIDB           2
END
PROCESS
STOP

The error message I get is:

                  SN FVS VARIANT -- RV:20230106.1

        STAND =                             MANAGEMENT CODE = NONE

               SUMMARY STATISTICS (BASED ON TOTAL STAND AREA)
----------------------------------------------------------------------------
       START OF SIMULATION PERIOD    REMOVALS/ACRE    AFTER TREATMENT GROWTH
     ---------------------------- ----------------- ---------------- CU FT
     TREES         TOP      MERCH TREES MERCH SAWLG         TOP      PER YR
YEAR /ACRE  BA SDI  HT  QMD CU FT /ACRE CU FT BD FT  BA SDI  HT  QMD ACC MOR
---- ----- --- --- --- ---- ----- ----- ----- ----- --- --- --- ---- --- ---
   0     0   0   0   0  0.0     0     0     0     0   0   0   0  0.0   0   0
   5     0   0   0   0  0.0     0     0     0     0   0   0   0  0.0   0   0
  10     0   0   0   0  0.0     0     0     0     0   0   0   0  0.0   0   0
At line 69 of file prtexm.f (unit = 58, file = 'fort.58')
Fortran runtime error: I/O past end of record on unformatted file

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
#0  0x7a12db
#1  0x7986f1
#2  0x792a1f
#3  0x7b48da
#4  0x797c69
#5  0x4790ca
#6  0x442023
#7  0x4c6764
#8  0x4d56d1
#9  0x4d57bc
#10  0x4013c4
#11  0x40152a
#12  0xf2597613
#13  0xf28826a0
#14  0xffffffff
wagnerds commented 1 year ago

Greetings,

Thank you for your submittal.

Please note that the Keyword Guide and the Essential FVS Guide specify the use of the PARMS keyword format to be the Keyword name followed by the year or cycle (which shall be right justified to column 20) and the PARMS statement should begin somewhere between columns 21 and 30. Defaults that are used when using the long form keyword calling are not applicable when using the PARMS statement, thus all parameters must be user supplied. There are no built-in checks for proper inputs when using the PARMS statement, so users must be extra cautious.

The proper format to designate a 'PLANT' keyword in every cycle using the PARMS style would be:

COMMENT
COLUMNS  10        20        30        40        50        60        70        80
....:....|....:....|....:....|....:....|....:....|....:....|....:....|....:....|
END
ESTAB
!Corrected Format for planting every cycle
PLANT             0 PARMS(LP,385, 85, 1, 0.75, 0)

!Corrected Format for planting 1st cycle
!PLANT             1 PARMS(LP,385, 85, 1, 0.75, 0)

!Corrected Format for planting in year 2025 cycle
!PLANT          2025 PARMS(LP,385, 85, 1, 0.75, 0)
END

It appears the version initially labeled as 'working' (PLANT PARMS(1,LP,385, 85, 1, 0.75, 0)) in the issue report, does not plant the intended 385 tpa of LP, but rather established 50 tpa of species 1, fir ('FR').

The version that was creating the I/O runtime error was attempting to establish species '0' which does not exist in the variant.
This appears to be causing a change to the sample tree output file pointer for this run. However, it should be possible to add an I/O error trap to the read call which we will look at including in a future release.

Thanks for your input.