Need to call StateCU executable from StateCU GUI

[smalers]

Recent changes to the StateCU build process are consistent with StateMod and result in executable filenames that are long, for example:

Executable Name	Description
statecu-14.0.0-gfortran-win-64bit-check.exe	Compiled with compiler runtime check options for troubleshooting, bigger and slower.
statecu-14.0.0-gfortran-win-64bit-o3.exe	Compiled with level 3 optimization for production, smaller and faster.
statecu-14.0.0-gfortran-win-64bit.exe	Copy of the o3 version, for production release.

The naming convention is verbose because it can be confusing to know which executable is being used, especially in the transition from 32-bit to 64-bit and in the case of StateMod Lahey to gfortran. I recommend sticking with this for now and at some point in the future when the Lahey version is no longer needed, the name can be shorted (but not yet).

My solution for both StateMod and StateCU is to distribute a command shell script such as statecu.cmd with the dataset. This script runs the longer named latest executable. Both the cmd and one or more exe files can live with the dataset.

If the executable for the GUI must be copied to a location in the GUI files, then the current executables can be copied to a GUI name as before.

If the GUI expects the executable to live with the dataset (by default in StateCU folder) then:

• If it runs statecu without the exe, then I think the cmd file would be similarly executed.
• If it runs statecu.exe, then the GUI code might need to be updated to look for statecu.cmd or just statecu.
• In either case, the GUI could try multiple filenames to be able to work with new and old conventions.
• My recent changes to make sure that the main program ALWAYS exits with status 0 or 1 should help the GUI know when there is an issue. I also changed so that the name of the log file is printed to the terminal so that it is easier for a user to know where it exists.

I have started to phase on a "require" comment for TSTool and StateDMI command files and think that a similar thing could help with model datasets. I'll add a separate issue for consideration.

[smalers]

As of StateCU 14.0.0, the executable has a verbose name and is distributed with statecu.cmd script to facilitate running. The StateCU GUI and dataset packaging need to be updated to be consistent. For example, see the following developer documentation.

Deployed Environment

[macphersonbr]

I don't believe I see any examples of StateCU datasets containing the StateCU .exe, but please correct me if I am wrong. I will work on packaging StateCU 14.0.0 into the GUI.

[macphersonbr]

I now see that the North Platte dataset has an executable in it - I will address that as well.

[smalers]

To be clear, it may make sense to do the following:

1. StateCU GUI uses the executable found in a dataset's StateCU folder, if included. Because the long executable name, StateCU GUI should call statecu.cmd. This will ensure that the GUI is using an executable that is known to work with the dataset. Users that run the model on the command line will also have access to an executable in the dataset folder without having to download the software.
2. If a dataset does not include an executable and statecu.cmd, use the executable version and statecu.cmd that are included in the StateCU GUI software in the bin folder.

The above will ensure that a specific executable is used if found, and by default an executable that has been tested with the GUI will be used. The size of the executable is relatively small compared to the full dataset so it is not an issue of disk space or space in a zip file.

A similar approach can be used for StateMod GUI, should that product be funded going forward. It is perhaps more important to package the executable with StateMod datasets because of the large number of StateMod software changes over time.

This strategy may cause some issues in projects where many copies of datasets are used (climate change modeling?). Depending on how those datasets are put together, probably don't want many copies of the executable. In this case, the GUI programs may need a way to indicate which executable is being used, There would probably also be a "runner" program of some type that would deal with executable location when making the many runs. I am not aware of how such multi-run datasets have been organized or distributed so I cannot comment.

[kelleythompson]

Personally I'm hoping that StateCU remains different from StateMod such that a new StateCU version is always backwards compatible with older datasets. Maybe a new version doesn't replicate results exactly - but the difference should only be minor (ie in floating point operations etc in a new compiler) or involve a true correction of an error which I don't think after all these years we really have. True that a new dataset may not run with an old StateCU version - but the responsibility can be on the user to download the newest GUI+statecu version. StateCU is deployed to a lot more people than StateMod, and most of those users don't care about CDSS datasets but just want to build and work on their own datasets. So it seems like our deployment of the StateCU executable within the GUI is still a simpler way to go than starting to worry about deploying it with datasets. Personal datasets get emailed all around and it would be so much nicer not to ever have an exe in a dataset (which kills emailing etc).

Although forgive me if I'm coming in un-informed etc. Thanks, Kelley

Kelley L. Thompson, P.E. Senior Lead Modeler - Modeling and DSS / Water Information Team

P 303.866.3581 ext 8261 | C 719.480.3423 1313 Sherman St., Suite 818, Denver, CO 80203 @.*** | www.water.state.co.us

On Tue, Sep 7, 2021 at 10:36 AM Steve Malers @.***> wrote:

To be clear, it may make sense to do the following:

1. StateCU GUI uses the executable found in a dataset's StateCU folder, if included. Because the long executable name, StateCU GUI should call statecu.cmd. This will ensure that the GUI is using an executable that is known to work with the dataset. Users that run the model on the command line will also have access to an executable in the dataset folder without having to download the software.
2. If a dataset does not include an executable and statecu.cmd, use the executable version and statecu.cmd that are included in the StateCU GUI software in the bin folder.

The above will ensure that a specific executable is used if found, and by default an executable that has been tested with the GUI will be used. The size of the executable is relatively small compared to the full dataset so it is not an issue of disk space or space in a zip file.

A similar approach can be used for StateMod GUI, should that product be funded going forward. It is perhaps more important to package the executable with StateMod datasets because of the large number of StateMod software changes over time.

This strategy may cause some issues in projects where many copies of datasets are used (climate change modeling?). Depending on how those datasets are put together, probably don't want many copies of the executable. In this case, the GUI programs may need a way to indicate which executable is being used, There would probably also be a "runner" program of some type that would deal with executable location when making the many runs. I am not aware of how such multi-run datasets have been organized or distributed so I cannot comment.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenCDSS_cdss-2Dapp-2Dstatecu-2Dfortran_issues_26-23issuecomment-2D914456665&d=DwMCaQ&c=sdnEM9SRGFuMt5z5w3AhsPNahmNicq64TgF1JwNR0cs&r=v8IOejxniM24GGbuf52hAajizwligqp4dTwlVwvfpSs&m=v94e0bjUAxDhVj6O5AC3Gx2MSKTcioZMOhlDqlhl5HQ&s=S9FI7gprX1Bp1Yt5aZ3HJkyHrMUte-kCO66FPSZQwrE&e=, or unsubscribe https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AC4LFGAC62KWKAHXEUGGXHTUAY5QHANCNFSM5CGPDESA&d=DwMCaQ&c=sdnEM9SRGFuMt5z5w3AhsPNahmNicq64TgF1JwNR0cs&r=v8IOejxniM24GGbuf52hAajizwligqp4dTwlVwvfpSs&m=v94e0bjUAxDhVj6O5AC3Gx2MSKTcioZMOhlDqlhl5HQ&s=9iRKK61_oldRHbSPaCREB4LaKOKuUnmJ_c3gghndoAc&e= . Triage notifications on the go with GitHub Mobile for iOS https://urldefense.proofpoint.com/v2/url?u=https-3A__apps.apple.com_app_apple-2Dstore_id1477376905-3Fct-3Dnotification-2Demail-26mt-3D8-26pt-3D524675&d=DwMCaQ&c=sdnEM9SRGFuMt5z5w3AhsPNahmNicq64TgF1JwNR0cs&r=v8IOejxniM24GGbuf52hAajizwligqp4dTwlVwvfpSs&m=v94e0bjUAxDhVj6O5AC3Gx2MSKTcioZMOhlDqlhl5HQ&s=Wh9V--U7Xo2T0eC44ZQ7J8pAD5IEqjIbb9hZMoW2bDc&e= or Android https://urldefense.proofpoint.com/v2/url?u=https-3A__play.google.com_store_apps_details-3Fid-3Dcom.github.android-26referrer-3Dutm-5Fcampaign-253Dnotification-2Demail-2526utm-5Fmedium-253Demail-2526utm-5Fsource-253Dgithub&d=DwMCaQ&c=sdnEM9SRGFuMt5z5w3AhsPNahmNicq64TgF1JwNR0cs&r=v8IOejxniM24GGbuf52hAajizwligqp4dTwlVwvfpSs&m=v94e0bjUAxDhVj6O5AC3Gx2MSKTcioZMOhlDqlhl5HQ&s=ur5j1OPbSta3sSeVq8DHz7qYDnTxElv7L5BjTnj-8Rw&e=.

[smalers]

Kelley makes a good point that if the datasets are typically distributed by email and including the executable causes issues with emailing, then maybe it does not make sense to include the executable with a dataset. On the other hand, there is a difference between "official" datasets that are published on the CDSS website and personal datasets where people can make their own decisions about the zip file.

Someone should think through how to handle updates to and distribution of model executables in typical use cases. For example, I thought that WWG said they copy StateMod executables to the StateMod folder to make it easier to run. I've been trying to streamline distribution so that there are as few steps as possible to download and run. It is possible for anybody to install a different executable in the dataset folder on their computer but the question is should there be an approved default that is distributed?

[kelleythompson]

Yes for StateCU I think there will/should be one approved default version - the most current version - that will be included within and distributed with the GUI install package. I assume we will pick just the 64bit (?) to distribute. If we hadn't mentioned, we (ie OIT) did recently extract all the old StateCU GUI VB and put it into a new .NET / visual studio project that is currently version controlled by OIT (insert emoji here) - (so not sure if that means it runs 64bit?). But also to explain more, a lot of engineers do make their own datasets for change cases - these get emailed to us - and we email around similar sets when we are reviewing change cases etc. - so think want to have the GUI have its own most current version of the StateCU exe that would get deployed so all the consultants don't have to mess with a separate exe in a separate location.

Thanks, Kelley

Kelley L. Thompson, P.E. Senior Lead Modeler - Modeling and DSS / Water Information Team

P 303.866.3581 ext 8261 | C 719.480.3423 1313 Sherman St., Suite 818, Denver, CO 80203 @.*** | www.water.state.co.us

On Tue, Sep 7, 2021 at 12:29 PM Steve Malers @.***> wrote:

Kelley makes a good point that if the datasets are typically distributed by email and including the executable causes issues with emailing, then maybe it does not make sense to include the executable with a dataset. On the other hand, there is a difference between "official" datasets that are published on the CDSS website and personal datasets where people can make their own decisions about the zip file.

Someone should think through how to handle updates to and distribution of model executables in typical use cases. For example, I thought that WWG said they copy StateMod executables to the StateMod folder to make it easier to run. I've been trying to streamline distribution so that there are as few steps as possible to download and run. It is possible for anybody to install a different executable in the dataset folder on their computer but the question is should there be an approved default that is distributed?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenCDSS_cdss-2Dapp-2Dstatecu-2Dfortran_issues_26-23issuecomment-2D914527662&d=DwMCaQ&c=sdnEM9SRGFuMt5z5w3AhsPNahmNicq64TgF1JwNR0cs&r=v8IOejxniM24GGbuf52hAajizwligqp4dTwlVwvfpSs&m=To6jXa9ApqFvL9R-Zhpi9uNVOYRxBbs6IrFH0xmtOTc&s=uQVITTWb3HVUmaipkkeIWJJkpYaCLCamzA7rtx1LzVU&e=, or unsubscribe https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AC4LFGF7ZC3LC4LL3OSSJALUAZK2FANCNFSM5CGPDESA&d=DwMCaQ&c=sdnEM9SRGFuMt5z5w3AhsPNahmNicq64TgF1JwNR0cs&r=v8IOejxniM24GGbuf52hAajizwligqp4dTwlVwvfpSs&m=To6jXa9ApqFvL9R-Zhpi9uNVOYRxBbs6IrFH0xmtOTc&s=sH9dp0W3ACwj_UF65t4jJQo8mHwfCBXROEeb_Y2uP7o&e= . Triage notifications on the go with GitHub Mobile for iOS https://urldefense.proofpoint.com/v2/url?u=https-3A__apps.apple.com_app_apple-2Dstore_id1477376905-3Fct-3Dnotification-2Demail-26mt-3D8-26pt-3D524675&d=DwMCaQ&c=sdnEM9SRGFuMt5z5w3AhsPNahmNicq64TgF1JwNR0cs&r=v8IOejxniM24GGbuf52hAajizwligqp4dTwlVwvfpSs&m=To6jXa9ApqFvL9R-Zhpi9uNVOYRxBbs6IrFH0xmtOTc&s=rJPF_GdRNQcA_6o7rtw7eef3My_g6CSjXMBsSIT5OLY&e= or Android https://urldefense.proofpoint.com/v2/url?u=https-3A__play.google.com_store_apps_details-3Fid-3Dcom.github.android-26referrer-3Dutm-5Fcampaign-253Dnotification-2Demail-2526utm-5Fmedium-253Demail-2526utm-5Fsource-253Dgithub&d=DwMCaQ&c=sdnEM9SRGFuMt5z5w3AhsPNahmNicq64TgF1JwNR0cs&r=v8IOejxniM24GGbuf52hAajizwligqp4dTwlVwvfpSs&m=To6jXa9ApqFvL9R-Zhpi9uNVOYRxBbs6IrFH0xmtOTc&s=Ovx0lWJMlXXbnTDdAMU0LfgM-GQm80XpKmS_ck0hE3g&e=.

[macphersonbr]

@smalers - I am going to work on incorporating the new .exe into the GUI installer. Is there a list of release notes for 14.0.0? I know that it has moved to 64 bit and that Erin and you both contributed some code changes. Could you please describe those code changes if they are pertinent to the average user?

[smalers]

The main enhancement that I am aware of is moving to 64-bit executable. Erin would need to be consulted as to whether there are any specific functional changes as I only reviewed the code for obvious coding issues but not CU functionality. Below is a list of things that I did that could go into release notes:

1. StateCU executable name is now more verbose to reflect the version, in order to avoid confusion.
2. The statecu.cmd script is provided to run StateCU in a general way and it runs the latest executable found in the same folder.
3. The response file (*.rcu), also referred to as the "scenario", can now be specified with our without the extension.
4. Exit code from the program is always set so that calling programs can check for 0 for success and non-zero (typically 1) for failure.

Several of the above can impact the GUI and actually make it better, but someone is probably going to need to update the code to fully take advantage. I do recommend that the release notes in user documentation reflect code changes and that it become a habit to keep them in sync.