FEEDBACK REQUESTED: Removal of support for LOOP_ORDER variable? #1278
-
Some of the METplus developers have discussed removing this option for various reasons (see below). We are soliciting feedback from the community to make sure that the removal of this option will not cause any negative effects on users that we have not considered. Please respond with any feedback for or against this work. Thank you! This feature is described in the METplus User's Guide here. Removing this option so that the logic of "LOOP_ORDER = processes" would always be used would greatly simplify the wrapper logic to be more maintainable and expandable. It would make it easier to expand the flexibility of time looping in METplus. For example, pb2nc could be configured to only run for each valid time regardless of how the time looping is defined. It would also make logging easier to read as log output listing the tool currently running could be displayed at the beginning of each execution that could be easily searched, i.e. "Running Wrapper: GridStat." The option is often confusing to new users. Wrappers for tools that process a series of times instead of running once per runtime, i.e. series_analysis or stat_analysis, currently cannot be run using "LOOP_ORDER = times" and will error out immediately if configured this way. The main motivation for allowing "LOOP_ORDER = times" was to get final output more quickly if processing many run times. However, this is typically achieved by configuring METplus to only process a single run time (remove or comment out [INIT/VALID]_END from config file), examining the output from that run, then configuring METplus to process more runtimes once the output for a single time has been approved. Removing the option would not change the results of existing METplus runs. The only difference would be the order of commands that are run (see documentation link above). |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
@georgemccabe Got the chance to think this over this morning. This change sounds good! |
Beta Was this translation helpful? Give feedback.
-
After many discussions, we have decided to move forward with the removal of the LOOP_ORDER config variable in favor of always executing the behavior that currently corresponds with LOOP_ORDER=processes. Follow issue #1687 for more information on the enhancement. The main advantage of running with LOOP_ORDER=times is you will be able to start viewing output while a use case is still running. For example, if you are running PCPCombine>RegridDataPlane>GridStat over a large range of run times, you would be able to start the use case and start examining the GridStat output files for the first run time while the rest of the times are still being processed. When I am setting up a new use case, I often run it for a single run time and examine the results before configuring it to process many run times. This can easily be accomplished by commenting out the VALID_END or INIT_END variable, which will result in the end time being set to the VALID_BEG or INIT_BEG value. If you feel that you need this functionality that will no longer be supported through the LOOP_ORDER=times setting and this solution is not sufficient for your needs, please create a new discussion topic to start a dialogue about other solutions. |
Beta Was this translation helpful? Give feedback.
After many discussions, we have decided to move forward with the removal of the LOOP_ORDER config variable in favor of always executing the behavior that currently corresponds with LOOP_ORDER=processes. Follow issue #1687 for more information on the enhancement.
The main advantage of running with LOOP_ORDER=times is you will be able to start viewing output while a use case is still running. For example, if you are running PCPCombine>RegridDataPlane>GridStat over a large range of run times, you would be able to start the use case and start examining the GridStat output files for the first run time while the rest of the times are still being processed. When I am setting up a new use case, I…