TITLE: multi_1 wave model physics upgrade CHANGE REQUEST CLASS: Major change DESCRIPTION OF CHANGE: This is a major upgrade of wave model physics. The global wave model system is now being changed to v 3.0.0 (to signify a major change in physics). This version will use WAVEWATCH III code v 4.05 which is going to be also implemented in parallel. Specific physics changes are outlined in the release notes for WAVEWATCH III v 4.05. Here we shall outline the changes made to the modeling system. The following changes have been made * All the model definition input files (inp files in fix/) have been changed to comply with WAVEWATCH III v 4.05 file format. NOTE -- The file formats for WAVEWATCH III v 4.05 are different from the file formats for WAVEWATCH III v 3.14.10, so you cannot use the wave modeling system multi_1.v3.0.0 with WAVEWATCH III v 3.14.10 and similarly you cannot use multi_1.v2.1.5 with WAVEWATCH III v 4.05 * The files in ush and scripts directory have been changed to account for the fact that WAVEWATCH III v 4.05 now has 53 possible outputs as opposed to 31 outputs in WAVEWATCH III v 3.14.10. NOTE -- The actal number of output files and fields that are generated in operations remains unchanged between v 2.1.5 and v 3.0.0 * The binary model definition files instead of being created on the fly for every cycle are now created and will be stored in the relevant com directory with a version number. All subsequent files will then first look for these model definition files and if it does not find them will create them and store them in the com directory. * This means that the first time in the day the prep, forecast and post cycle will run slightly slower to allow for the generation of these files and since the same com directory is used for all the other cycles those will run faster. * Since the model definition files will be stored in the com with a relevant model version in the file name, anytime the operational system upgrades to a new version then a new model definition file will be generated, thus precluding the risk of the system grabbing the wrong definition file. * This approach is being used because the construction of model definition files in WAVEWATCH III v 4.05 has become computationally more intensive due to storing additional information associated with new physics packages. * Output files and file formats are unchanged * The new physics package is computationally more intensive so changes to the forecast resource usage needs to be made * Also the forecast, prep and post steps will run a couple of minutes slower on the cycles where model definition files have to be created (12 z cycle when first implemented and every 0 z cycle after that) * The older grids (akw,wna and enp) were generating grib1 files for backward compatibility. These files are being sent to awips. The grib1 files will continue to be generated but also direct generation of the grib2 files will begin with this implementation. The outputs generated for grib2 will be same as those for all the other output grids (glo_30m, ak_10m etc.) and the naming scheme will follow the standard apporach. GEMPAK grids are already being generated from the grib2 files. * The wave steepness code has moved away from using putgb for grib generation and uses direct calls for grib generation. This removes dependancy on wrapper codes like putgb. readgb is still being used BENEFIT OF CHANGE: The benefit of change is the improved wave physics. The new physics impacts forecast results in the following ways * Reduces known wave height biases in swells. This has a significant impact in swells propagating across the ocean basin * Removes persistent biases in the Southern Hemisphere which is related to the new treatment of swells. * Uses new physics terms for wave growth and dissipation, which reduces the random error * Overall the total error is reduced by over 30% (based on error metrics computed over a year long hindcast study) USER IMPACT STATEMENT: External community will not have to worry about technical issues since data delivery formats are not changing. However since the new physics packages will alter the quality of forecasts, the community will have to get prior knowledge. For this purpose, a 30-day parallel run and a 75-day TIN will be issued. TECHNICAL IMPACT STATEMENT: Minimal since the file formats and associated output types are not changing. RISKS: PROPOSED IMPLEMENTATION DATE: TIME: BUGFIXES v 3.0.2 05/08/2012 On implementation of new model the multi_2 and mens models crashed. To alleviate that the following changes were made * Create model and version number specific wind and ice forcing for multi_1 This is being done because the icean_5m and gfs_30m forcing files that are created by multi_1 are used by multi_2 and mens. Unfortunately v 4 of WAVEWATCH III is not backward compatible so these forcing files have to be created again using older version of WAVEWATCH III. To do this a prep step has been added to multi_2 processing (still in the flat file structure). v 3.0.3 05/15/2012 The GRIB2 file for wna, enp and akw are created directly other than converting from grib1. The file name and the number of parameters for the new grib2 file is changed, but it was not included in the TIN. A work around solution was to turn back on cnvgrib step to create the old grib2 file and use that file as input to create the gempak file. v 3.0.5 09/12/2012 The lack of ice lead to waves reaching the northern edges of the arctic grid. The grid at these reaches was found to be unstable. To correct this the time step for the ao_30m grid was changed. Also the top edge was masked out. This impacts only one file v 3.0.6 09/26/2012 A new set of points to support NWPS. Slight changes needed to be made to scripts that extracted point outputs to make sure they could handle the NW-* naming scheme