FVS directory structure

---

FOR REFERENCE ONLY, DETAILS HAVE CHANGED SIGNIFICANTLY

for current docs, see README

---

In order to batch process runs with this system, it's important that the input files conform to this file structure outlined below... Work in progress; three potential strategies outlined below

WE WILL USE STRATEGY 1... 2&3 are here for reference only

Naming requirements

All names should be alphanumeric (no spaces, dashes, underscores, etc)

• Variants will be the fvs code used in the .exe file (FVSpn.exe = pacific northwest = pn )
• Rxs will should have an easily recognizable nomanclature (60 year rotation with commercial thin = CT60 )
• Stand ids will be the numeric Condition ID used as the representative plot (1332)
• Offsets are handled automatically if there is the appropriate line in the keyfile: "Offset = ___"

Data Directory Structure (strategy 1)

One key per Rx and Stand

{{Condition ID}}_{{Rx ID}}
   |---- {{Condition ID}}_{{Rx ID}}_original.key
   |---- {{Condition ID}}.fvs
   |---- {{Condition ID}}_{{Rx ID}}.variant     <= this file contains the variant code to be used

Example:

1332_CT60
   |---- 1332_CT60_original.key
   |---- 1332.fvs
   |---- 1332_CT60.variant 

Pros

• Small, fast, self contained runs
• Output files (ex: alt_cut_vol.txt, etc) will be 1:1 with stands

Cons

• Lots of small processes to manage; QC issues
• Overall speed hit due to overhead time of each run (?)

Data Directory Structure (strategy 2)

One key per Rx and Variant. Each key would reference all of the stands in that variant.

{{Variant}}_{{Rx ID}}
   |---- {{Variant}}_{{Rx ID}}_original.key
   |---- {{Variant}}_{{Rx ID}}.variant     <= superflous but necessary for consistency
   |---- {{Condition ID}}.fvs
   |---- {{Condition ID}}.fvs
   |---- ...
   |---- {{Condition ID}}.fvs

Example:

pn_CT60
   |---- pn_CT60_original.key
   |---- pn_CT60.variant 
   |---- 1332.fvs
   |---- 1337.fvs
   |---- ...
   |---- 6056.fvs

Pros

• Fewer processes to manage, easier to manually QC
• Faster due to less overhead
• Easier to parrallelize
• Easier maintenance of input files

Cons

• Output files (ex: alt_cut_vol.txt, etc) will be 1:Many with stands
• Long running processes, slow iteration time
• More difficult to detect subtle failures
• Harder to organize output files

Data Directory Structure (strategy 3)

One key per Stand. Each key would be run under a single variant and reference all of the prescriptions for that variant. Effectively would be running multiple stands with the same treelists but different rxs all stuffed into a single key file.

{{Condition ID}}
   |---- {{Condition ID}}_original.key  <= Would contain multiple stands, each a copy of the condition ID with different Rx applied.
   |---- {{Condition ID}}.variant     
   |---- {{Condition ID}}.fvs

Example:

1332
   |---- 1332.key
   |---- 1332.variant 
   |---- 1332.fvs

Pros

• All the condition related info in one place.

Cons

• Prepping FVS files?

Calcs

Strategy                                          Rx          Stands        Variants       Total data directories
Strategy 1 (One key per Rx * Stand)               19          18,324        --             348,156
Strategy 2 (One key per Rx * Variant)             19          --            7              133
Strategy 3 (One key per Stand)                    --          18,324        --             18,324

Batch runs

Each data directory will contain one and only one _original.key file.

The batch processing system will be set up to accept a batch directory which contains multiple data directories

Example:

BatchRun1
  |-- 6056_CT60
       |---- 6056_CT60_original.key
       |---- 6056.fvs
       |---- 6056_CT60.variant 
  |-- 1332_CT60
       |---- 1332_CT60_original.key
       |---- 1332.fvs
       |---- 1332_CT60.variant