-
Notifications
You must be signed in to change notification settings - Fork 26
Description
Describe the Enhancement
I am repurposing this existing issue to better define the multi-variate MODE enhancements that are needed.
-
While the existing
MODEMultivarConfig_default
file exists in the repository, it is NOT actually read by Multi-Variate MODE! In all cases, MODEConfig_default is read instead. Need to understand why, and either update MODE to read it in the right circumstances or just remove it from the repo. -
If
MODEMultivarConfig_default
is retained, modify thenc_pairs_flag
setting in it to specify it as a dictionary, just like it is specified in MODEConfig_default. This is needed to make the logic of the MODE wrapper clear and consistent. -
Make large updates to the multi-variate logic, as described below.
- As of MET version 10.1.0, multi-variate MODE generates output NetCDF files named
f_super.nc
ando_super.nc
. However, it does not actually write out any object statistics. - Recommend that it continue to write out the super object information, but write out both fields to the standard MODE NetCDF output file instead (i.e. *_obj.nc).
- Add a new config option that is an array of booleans with the same length as the number of forecast and observation fields:
multivar_intensity_flag = [ TRUE, TRUE, FALSE ];
(default will be FALSE for all) - After generating the super objects, loop through the
multivar_intensity_flag
booleans:- If all
multivar_intensity_flag
booleans are false, run MODE once on the binary 0/1 super objects to generate geometric object statistics and write them to the output "*_obj.txt" file. - Otherwise, for each
multivar_intensity_flag
boolean flag that is true, run MODE once substituting in the raw intensity values for the corresponding fcst/obs fields. The object definition has already been performed, but we're just regenerating the statistics using the intensities for those fields. Write the output to the "*_obj.txt" output file. For any FALSE booleans, the intensity statistics will contain missing values. - So the "*_obj.txt" may now contain output for multiple fields with different intensity values and potentially total interest values. Need to differentiate between them in the output in the FCST_VAR and OBS_VAR columns. Recommend including the forecast and observation field names in those output columns.
- Be sure to check the
nc_pairs_flag
option and write intensity values to the NetCDF file, as requested by the user. - Add a new config option that allows the user to change the forecast and observation field names. Currently the super object output name is ‘super’, but users may be running multivariate MODE on multiple complex events (dryline/blizzard), and it will be beneficial to have a way to differentiate between the output
- Add
multivar_name="";
to change the name of the multivariate mode output as listed in the ascii file output, for example. (default will be "super") - For example, if we define
multivar_name = "blizzard";
and we request intensity output for visibility, our ascii file(s) should append this to the FCST_VAR and OBS_VAR names e.g. blizzard_vis/vis_blizzard (preferred order?)- If intensity isn’t requested for any field, the name would be blizzard for the geometric object statistics?
- Add
- If all
- Other considerations
- Determine whether there should be separate MODE output files for each field where intensity statistics are requested, or all output contained in a single file
- Do what makes sense, when thinking about parallelization
- No need to keep mode runs from the individual fields - cuts down on processing time
- Keep this info in memory for continuing the mvmode process
- Determine whether there should be separate MODE output files for each field where intensity statistics are requested, or all output contained in a single file
Time Estimate
Estimate the amount of work required here.
Issues should represent approximately 1 to 3 days of work.
Sub-Issues
Consider breaking the enhancement down into sub-issues.
- Add a checkbox for each sub-issue here.
Relevant Deadlines
List relevant project deadlines here or state NONE.
Funding Source
2700042 WPC
Define the Metadata
Assignee
- Select engineer(s) or no engineer required
- Select scientist(s) or no scientist required
Labels
- Select component(s)
- Select priority
- Select requestor(s)
Projects and Milestone
- Select Repository and/or Organization level Project(s) or add alert: NEED PROJECT ASSIGNMENT label
- Select Milestone as the next official version or Future Versions
Define Related Issue(s)
Consider the impact to the other METplus components.
- METplus, MET, METdatadb, METviewer, METexpress, METcalcpy, METplotpy
Related to MET Issues: - Add support for Multi-Variate MODE #1184
- MODE-Multivar boolean logic from config file #1282
- MODE-Multivar processing chain #1284
Enhancement Checklist
See the METplus Workflow for details.
- Complete the issue definition above, including the Time Estimate and Funding Source.
- Fork this repository or create a branch of develop.
Branch name:feature_<Issue Number>_<Description>
- Complete the development and test your changes.
- Add/update log messages for easier debugging.
- Add/update unit tests.
- Add/update documentation.
- Push local changes to GitHub.
- Submit a pull request to merge into develop.
Pull request:feature <Issue Number> <Description>
- Define the pull request metadata, as permissions allow.
Select: Reviewer(s) and Linked issues
Select: Repository level development cycle Project for the next official release
Select: Milestone as the next official version - Iterate until the reviewer(s) accept and merge your changes.
- Delete your fork or branch.
- Close this issue.