Why are max trees set to 3000?

[jgrn307]

Hi there -- we are trying to run FVS with an input tree list of ~ 4000 trees (its a big plot, basically) -- it looks like there is a hardcoded 3000 limit -- is there a particular reason for this or is this legacy from older FVS where RAM was more limited? Can you remove the max tree limit or set it to some massive number that will never causes an issue?

[wagnerds]

Greetings!

The tree record limit is controlled by the MAXTRE variable in the PRGPRM.F77 file specific to the variant you are using. For example if using the CA variant, you can change the limit of MAXTRE in ca/common/PRGPRM.F77.

However, according to our documentation you should not change the limit if using a ORGANON variant as apparently the ORGANON limit is 2,000 to correspond to other areas in the code where that number was hardcoded.

If not using an ORGANON variant, I've been told other users have had success modifying the MAXTRE value to a number greater than 10,000, though our documentation recommends keeping the number as a multiple of 3 to better conform with how the tripling algorithm in FVS functions.

Another alternative may be to bundle multiple trees into a single record. For example if you have 10 trees with matching attributes (species, dbh, ht, etc.) you can use the tree_count field to indicate that the record represents multiple trees instead of each individual tree getting it's own record line.

Ideally trees lists would be dynamically allocated in FVS, but refactoring that prior to a more broad scale reworking of FVS is not currently on our program of work.

Let me know if you have any more questions. Thanks.

[DonRobinsonESSA]

I think the original MAXTRE value that Al Stage used was 1,350. I don't know how he decided that! In the development of the BC variant (1990s) we were asked to allow for a larger number, so (mea culpa) I chose 3,000, which met the need at the time. That undocumented decision predates GitHub or its SourceForge predecessor, but I guess that is story behind the current (Organon excepted) norm of 3,000. I can confirm that ESSA has tested using 10,000 to see if anything obvious was broken. Nothing broke in simple tests, but 3,000 now seems to be the norm.

My recollection is that the "bundling" approach Dan describes above is actually used to track snags in the FFE, to keep snag-lists to a manageable size.

[jgrn307]

Is there any particular reason this can't just be arbitrarily set to be "infinite"? I don't remember much about fortran, is this a language where you have to reserve the variable size ahead of time (so there would be a RAM impact at load)? If so, would you consider adding a command line parameter to allow the user to set a max tree value themselves (rather than tweaking the source code and rebuilding it)?

[DonRobinsonESSA]

Interesting question! I suppose it could be made arbitrarily large, but is that a good idea? AFAIK Fortran sets aside memory for variables before doing anything. It is very unlike C. So I think you are correct that in legacy/classic Fortran RAM is allocated/consumed when the program loads. In more modern Fortran I think you can take a more C-like "malloc()" approach, but I've never done this. And I suppose you could then add a command line argument and malloc() your way over all the variables that have a MAXTRE dimension. IMHO that would be a very big job and would require testing against unexpected results and corner cases. What would be the specific payback in this anticipated use of FVS? At some point you may need to consider the simplification of "bundling" input records (Dan's earlier point), and also think about how the concepts behind the FVS keywords TRIPLE/COMPRESS/NOTRIPLE. COMPRESS is actually similar to bundling based on a few eigen-properties. In the early days (before the 640k RAM limit was breached) Al Stage gave thought to this and I think (besides the RAM limits that might have been behind the original limit of MAXTRE=1,350) arrived at the idea of "good enough" resolution; a world in which 100,000 detailed tree records wasn't going to inform your management any better than a world with 1,000 records. Stage wanted to have enough records in the simulation to mimic natural variation (you could call it error), but only enough to capture that adequately. For fun, find out the minimum number of records you must have to do a simulation, which is the reverse case, and see what happens with those records. My two cents.

[d-diaz]

FWIW, when I have worked with datasets that come with "too many" plots or trees (e.g., using plot records from TreeMap pixels within stand polygons), I have previously followed an approach like @DonRobinsonESSA and @wagnerds describe to condense the pixels/treelists into a stand table by binning live and dead trees for each species into diameter and height classes and summing their counts. Unless you are simulating complicated plot- or point-based silvicultural treatments, I don't think there's a benefit to retain a large number of distinct plot and tree records considering FVS won't produce meaningfully different outcomes and there could be some non-trivial cost (time, $) for superfluous computation depending on the scale of your modeling efforts.

[jgrn307]

If I'm using the fire and fuels submodel, can I still use the "bundling" approach where I bin multiple trees together? Related: is there a "standard" set of binning I should consider (what intervals are recommended for DBH and Ht, for instance)? As you noted, I'm using TreeMap (and we are developing our own product that has some similarities with TreeMap) so we have a LOT of trees.

[wagnerds]

I can't think of a reason off the top of my head why binning tree records would be a problem when using FFE.

I don't believe there is a "standard" for binning records. Probably depends on your objectives and what questions you are trying to answer. I've always been apprehensive about the level of precision I often see used from imputed data or data derived from LiDAR returns. Is using these kinds of data at a precision of fractions of a inch dbh or fractions of a foot in height appropriate? Or is doing so implying a level of precision that may not actually be representative of the conditions on the site, especially with imputed data?

I would recommend trying a few different binning scenarios at smaller scales and see what works best for your intended application.

[DonRobinsonESSA]

Hi all – If binning is the approach (and it sounds like a good candidate to me) then you’ll have to decide on the level of resolution you need. Whatever dimensions you choose (species categorical would probably be a good one), it will need to target reduction to the 3,000 limit (or another limit you decide on before rebuilding your EXE/DLL). One approach we recently used was begun with a cluster analysis at the STAND level, where we have about 30,000 stands of fairly high resolution GIS data and FIA data, and wanted to reduce it to the 10,000 range to allow us to do multiple iterations of scenarios we were exploring. And that was all run an AWS over multiple computers, etc. So I’d also suggest you ask yourself if your problem can reasonably include a stand level, which would reduce the tree-count and increase the stand-count. If that approach is possible, then you can also use the stop/restart capability of FVS to make management decisions mid-run at a multi-stand level, if that is relevant to your problem. We used R-scripts to implement this, also creating new stands on the fly when we needed to split a stand when we hit a constraint imposed by a scenario. HTH, Don * Donald Robinson, MSc, RPBio* Associate Sr. Systems Ecologist ESSA Technologies Ltd. c: *778.554.7727* e: ***@***.*** Website <http://www.essa.com/> | LinkedIn <www.linkedin.com/in/donald-robinson-480a939a> | ResearchGate <http://www.researchgate.net/profile/Donald_Robinson3> | πάντα ῥεῖ *From:* jgrn307 ***@***.***> *Sent:* Saturday, January 10, 2026 12:10 PM *To:* USDAForestService/ForestVegetationSimulator < ***@***.***> *Cc:* Donald Robinson ***@***.***>; Mention < ***@***.***> *Subject:* Re: [USDAForestService/ForestVegetationSimulator] Why are max trees set to 3000? (Issue #55) *jgrn307* left a comment (USDAForestService/ForestVegetationSimulator#55) <#55 (comment)> If I'm using the fire and fuels submodel, can I still use the "bundling" approach where I bin multiple trees together? Related: is there a "standard" set of binning I should consider (what intervals are recommended for DBH and Ht, for instance)? As you noted, I'm using TreeMap (and we are developing our own product that has some similarities with TreeMap) so we have a LOT of trees. — Reply to this email directly, view it on GitHub <#55 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AS3AVQLPHOXSDW5NCPTVQ5T4GFMCRAVCNFSM6AAAAACOY4Q7SKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMZTGQ2TEMRYG4> . You are receiving this because you were mentioned.Message ID: < ***@***.***>

[d-diaz]

@jgrn307 I'd recommend aggregating from pixels to stand tables. It doesn't sound like you need to retain variability across the stand, but if you do want to retain something between the pixel-scale and polygon scale as a pseudo-plot, I'd suggest scripting a process to summarize pixels to hexagons or a coarser grid of some kind as the easiest solution. When you consolidate pixels into a for the whole stand polygon or for each "plot" into a stand table, I'd recommend starting by grouping all the tree records for each species into a table with diameter classes binned by DBH at 0.5" increments and height by 2 ft increments. See how much compression that gives you in terms of tree records per stand polygon. Then, increase bin widths as needed or increase the area of represented by pseudo-plots.

While you could adopt much more sophisticated methods to generate sub-stand pseudo-plots, FVS isn't likely to provide you the level of sensitivity and predictive precision that would meaningfully leverage this information about spatial variability across a stand anyways, even if you did try to simulate spatially variable silviculture or disturbance within a stand (which isn't straightforward, and for which FVS hasn't been trained or validated).

A lot more of your modeling outcomes and the credibility of them will be determined by the calibration and keyword settings you employ for defining SDIMAX and adjusting growth and mortality rates rather than the number of records in your incoming tree lists.