Unrecognized STDINFO variables prevent DSNOUT from being executed

[d-diaz]

I'm noticing a strange error on many simulations when an unrecognized location code or habitat code is populated with STDINFO keyword. Although the .out file gives warning and that default location or habitat code will be used, another error shows up that the DSNOUT keyword was used in the wrong context and was ignored:

DATABASE   DATABASE KEYWORDS:

********   FVS16 ERROR:  KEYWORD ENTERED IS USED IN WRONG CONTEXT AND WAS IGNORED.  RECORDS READ=  20

           DSNOUT DATA BASE CAN NOT BE REDEFINED. DSN FOR OUTPUT REMAINS: FVSOut.db

Here is are an example keyfile with an unrecognized habitat type you could use to reproduce this for the FVSpn variant:

STDIDENT
00162008020503007825141

STANDCN
31352649010690

STDINFO          609     41799
INVYEAR         2008

NOTREES

TIMEINT            0         5
NUMCYCLE           1

DATABASE
DSNOUT
bad_pn_habitat.db
SUMMARY            2
END

PROCESS
STOP

Here is an example keyfile with an unrecognized location code you could use to reproduce this for the FVStt variant:

STDIDENT
00162008020503007825141

STANDCN
31352649010690

STDINFO          404     41790
INVYEAR         2008

NOTREES

TIMEINT            0         5
NUMCYCLE           1

DATABASE
DSNOUT
bad_tt_location.db
SUMMARY            2
END

PROCESS
STOP

If I build FVS using an earlier version (commit b4c0599432f341cb0aa98c9334d03bdba47ebbb0), this error doesn't occur.

It seems like whatever bug is causing this behavior was introduced in commit fdb993b26e27c05093d64481654065aeb94d3f4a.

[DavidLRfs]

Hi David,

What has happened here is that the error was encountered which triggered a write to the FVS_Error output table. That action locked the Output database name. Then the DSNOUT was processed and failed. So, what you would want to do is move that DSNOUT keyword to the top of your keyword set so that the output database name is set before any errors can occur.

Have a good day. Lance

[Forest Service Shield] Lance R. David Lead Systems Analyst Forest Service Contractor (ICF / Creative) Washington Office -Detached, Forest and Rangelands Management / Vegetation Ecology p: 970-295-5856 @.**@.> 2150 Centre Ave, Bldg A Fort Collins, CO 80526 www.fs.usda.govhttp://www.fs.usda.gov/

From: David Diaz @.> Sent: Thursday, October 17, 2024 1:00 PM To: USDAForestService/ForestVegetationSimulator @.> Cc: Subscribed @.***> Subject: [USDAForestService/ForestVegetationSimulator] Unrecognized STDINFO variables prevent DSNOUT from being executed (Issue #47)

I'm noticing a strange error on many simulations when an unrecognized location code or habitat code is populated with STDINFO keyword. Although the .out file gives warning and that default location or habitat code will be used, another error shows up that the DSNOUT keyword was used in the wrong context and was ignored:

DATABASE DATABASE KEYWORDS:

**** FVS16 ERROR: KEYWORD ENTERED IS USED IN WRONG CONTEXT AND WAS IGNORED. RECORDS READ= 20

       DSNOUT DATA BASE CAN NOT BE REDEFINED. DSN FOR OUTPUT REMAINS: FVSOut.db

Here is are an example keyfile with an unrecognized habitat type you could use to reproduce this for the FVSpn variant:

STDIDENT

00162008020503007825141

STANDCN

31352649010690

STDINFO 609 41799

INVYEAR 2008

NOTREES

TIMEINT 0 5

NUMCYCLE 1

DATABASE

DSNOUT

bad_pn_habitat.db

SUMMARY 2

END

PROCESS

STOP

Here is an example keyfile with an unrecognized location code you could use to reproduce this for the FVStt variant:

STDIDENT

00162008020503007825141

STANDCN

31352649010690

STDINFO 404 41790

INVYEAR 2008

NOTREES

TIMEINT 0 5

NUMCYCLE 1

DATABASE

DSNOUT

bad_tt_location.db

SUMMARY 2

END

PROCESS

STOP

If I build FVS using an earlier version (commit b4c0599432f341cb0aa98c9334d03bdba47ebbb0https://github.com/USDAForestService/ForestVegetationSimulator/commit/b4c0599432f341cb0aa98c9334d03bdba47ebbb0), this error doesn't occur.

It seems like whatever bug is causing this behavior was introduced in commit fdb993b26e27c05093d64481654065aeb94d3f4ahttps://github.com/USDAForestService/ForestVegetationSimulator/commit/fdb993b26e27c05093d64481654065aeb94d3f4a.

- Reply to this email directly, view it on GitHubhttps://github.com/USDAForestService/ForestVegetationSimulator/issues/47, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZVWHW3JDFILGO7R26FGJXDZ4ACMXAVCNFSM6AAAAABQEMWD7OVHI2DSMVQWIX3LMV43ASLTON2WKOZSGU4TKNJRGIZTEOA. You are receiving this because you are subscribed to this thread.Message ID: @.***>

This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

[d-diaz]

Thanks for the speedy reply, @DavidLRfs! I can confirm that this change resolves the errors I was encountering. Since these changes to errgro.f may require changes by any user with existing templates that may introduce errors or warnings above a call to DSNOUT to continue using FVS the same way, I wanted to ask if there is a way to adjust the changes to errgro.f to support backward-compatability? Would it be possible to cache errors and warnings encountered after the keyfile has been read for a stand before starting to write to DB?

[DavidLRfs]

Hi David,

It could be done but would not be very simple, because the errors are written immediately to the Main Output file so that their association with keywords resulting in error or warning can be known by the user. At that same time, they are also written to the FVS_Error output DB table. To cache the messages for the FVS_Error table and then write to the database at a later time would be more code and process overhead that I don't really think we can justify. Practically anything is possible though.

Cheers, Lance

From: David Diaz @.> Sent: Thursday, October 17, 2024 2:13 PM To: USDAForestService/ForestVegetationSimulator @.> Cc: David, Lance (CTR) - FS, CO @.>; Mention @.> Subject: Re: [USDAForestService/ForestVegetationSimulator] Unrecognized STDINFO variables prevent DSNOUT from being executed (Issue #47)

Thanks for the speedy reply, @DavidLRfshttps://github.com/DavidLRfs! I can confirm that this change resolves the errors I was encountering. Since these changes to errgro.f may require changes by any user with existing templates that may introduce errors or warnings above a call to DSNOUT to continue using FVS the same way, I wanted to ask if there is a way to adjust the changes to errgro.f to support backward-compatability? Would it be possible to cache errors and warnings encountered after the keyfile has been read for a stand before starting to write to DB?

- Reply to this email directly, view it on GitHubhttps://github.com/USDAForestService/ForestVegetationSimulator/issues/47#issuecomment-2420466537, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZVWHW2SFZEG2DHL43WAPPTZ4AK53AVCNFSM6AAAAABQEMWD7OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRQGQ3DMNJTG4. You are receiving this because you were mentioned.Message ID: @.***>

This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

[d-diaz]

Fair enough. Would recommend updating DBSUserGuide and/or FVS Keyword Guide to encourage users to specify DSNOUT above all other keywords because it may be ignored if any warning or error is raised. Probably worth mentioning in Release Notes that this is a potentially breaking change for users with existing keyfiles, but with a known workaround of putting DSNOUT first.

Hopefully the GUI will automatically insert DSNOUT at the top?

[DavidLRfs]

Thank you, David.

From: David Diaz @.> Sent: Thursday, October 17, 2024 4:30 PM To: USDAForestService/ForestVegetationSimulator @.> Cc: David, Lance (CTR) - FS, CO @.>; Mention @.> Subject: Re: [USDAForestService/ForestVegetationSimulator] Unrecognized STDINFO variables prevent DSNOUT from being executed (Issue #47)

Fair enough. Would recommend updating DBSUserGuide and/or FVS Keyword Guide to encourage users to specify DSNOUT above all other keywords because it may be ignored if any warning or error is raised. Probably worth mentioning in Release Notes that this is a potentially breaking change for users with existing keyfiles, but with a known workaround of putting DSNOUT first.

Hopefully the GUI will automatically insert DSNOUT at the top?

- Reply to this email directly, view it on GitHubhttps://github.com/USDAForestService/ForestVegetationSimulator/issues/47#issuecomment-2420729177, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZVWHWYYROGZS6LPDESORQ3Z4A25NAVCNFSM6AAAAABQEMWD7OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRQG4ZDSMJXG4. You are receiving this because you were mentioned.Message ID: @.***>

This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.