Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

update MOM6 #283

Closed
jiandewang opened this issue Nov 18, 2020 · 6 comments
Closed

update MOM6 #283

jiandewang opened this issue Nov 18, 2020 · 6 comments
Assignees
@jiandewang
Labels
enhancement New feature or request

Comments

@jiandewang
Copy link
Collaborator

jiandewang commented Nov 18, 2020 •
edited
Loading

Description

GFDL updated their MOM6 main branch on 20201022, need to update EMC MOM6 repo correspondingly. This updating involves some MOM6 parameter default value changes which will require the generation of new baseline.

Solution

Update EMC MOM6 repo and MOM_input to reflect the parameter changes, and run the coupled system.

Related to

Updating of MOM6 repo issue can be found at
NOAA-EMC/MOM6#39
@jiandewang jiandewang added the enhancement New feature or request label Nov 18, 2020
@JessicaMeixner-NOAA
Copy link
Collaborator

@jiandewang I thought this was coming in two parts. First we reproduce the existing baselines which you worked so hard to do (which requires updates to parameter files, but not baselines) and then changing values which would require a new baseline.

@jiandewang
Copy link
Collaborator Author

@JessicaMeixner-NOAA for 0.25x0.25 ocean got b4b identical results, for 0.5x0.5 ocean results are not b4b identical with current setting, but by setting vertex-shear=F, results are b4b identical. For 1x1, results are not b4b identical regardless of vertex-shear setting.

@JessicaMeixner-NOAA
Copy link
Collaborator

I thought based on our conversation with @AvichalMehra-NOAA that the original strategy: maintaining b4b answers was still the strategy.

@jiandewang
Copy link
Collaborator Author

@JessicaMeixner-NOAA I tried all my best and did all I could, it just didn't come as we wished. Our discussion with @AvichalMehra-NOAA also include the testing of 35day run to see the impact.

This was referenced Nov 18, 2020
Merged
Merged
@aerorahul
Copy link
Contributor

aerorahul commented Nov 20, 2020 •
edited
Loading

@jiandewang
This PR does not fix the issue with compiling the standalone MOM6 within UFS.
That is not an issue the GFDL/main branch.

There is a bug in the way the wave forcing subroutine was being called with incorrect number of arguments.

This option is triggered by adding the following to CMAKE_FLAGS if you are using just build.sh in the ufs-weather-model.

CMAKE_FLAGS="-DMOM6SOLO=ON -DS2S=ON -DDATM=ON" BUILD_VERBOSE=1 BUILD_JOBS=6 BUILD_DIR=build-datmmom6 ./build.sh

[ 99%] Building Fortran object MOM6-interface/CMakeFiles/mom6solo.dir/MOM6/config_src/solo_driver/MOM_driver.F90.o
cd /Users/rmahajan/scratch/UFSwork/weather-develop/build-datmmom6/MOM6-interface && /opt/modules/gnu-9.3.0/mpich/3.3.1/bin/mpifort -DENABLE_QUAD_PRECISION -DGFS_PHYS -DINTERNAL_FILE_NML -Duse_libMPI -Duse_netCDF -I/Users/rmahajan/scratch/UFSwork/weather-develop/build-datmmom6/MOM6-interface/mod -I/Users/rmahajan/scratch/UFSwork/weather-develop/build-datmmom6/MOM6-interface/mod_solo -I/Users/rmahajan/scratch/UFSwork/weather-develop/MOM6-interface/MOM6/config_src/dynamic -I/Users/rmahajan/scratch/UFSwork/weather-develop/MOM6-interface/MOM6/src/framework -I/Users/rmahajan/scratch/UFSwork/weather-develop/FMS/include -I/Users/rmahajan/scratch/UFSwork/weather-develop/FMS/fms -I/Users/rmahajan/scratch/UFSwork/weather-develop/FMS/mpp/include -I/Users/rmahajan/scratch/UFSwork/weather-develop/build-datmmom6/FMS/mod -I/opt/modules/gnu-9.3.0/mpich-3.3.1/netcdf/4.7.4/include -g -fbacktrace -fdefault-real-8 -fdefault-double-8 -Waliasing -fcray-pointer -fconvert=big-endian -ffree-line-length-none -fno-range-check -fbacktrace -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk -mmacosx-version-min=10.15 -Jmod_solo -c /Users/rmahajan/scratch/UFSwork/weather-develop/MOM6-interface/MOM6/config_src/solo_driver/MOM_driver.F90 -o CMakeFiles/mom6solo.dir/MOM6/config_src/solo_driver/MOM_driver.F90.o
/Users/rmahajan/scratch/UFSwork/weather-develop/MOM6-interface/MOM6/config_src/solo_driver/MOM_driver.F90:491:79:

  491 |       call Update_Surface_Waves(grid, GV, US, time, time_step_ocean, waves_csp)
      |                                                                               1
Error: Missing actual argument for argument 'forces' at (1)
make[2]: *** [MOM6-interface/CMakeFiles/mom6solo.dir/MOM6/config_src/solo_driver/MOM_driver.F90.o] Error 1
make[1]: *** [MOM6-interface/CMakeFiles/mom6solo.dir/all] Error 2
make: *** [all] Error 2

@jiandewang
Copy link
Collaborator Author

close

epic-cicd-jenkins pushed a commit that referenced this issue Apr 17, 2023
@JeffBeck-NOAA
Remove leading 0 from post task dependencies (#283)
2d93671 
* Changes to post file names to make model lowercase and move ${fhr} to three values instead of two

* Change "rrfs" to "${NET}" instead

* Add missing "f" to file name

* Remove restriction on ${fhr} being only two digits

* Change fhour to three digit variable and at "f" to filename for Python plotting script.

* Add new "post_fhr" variable to support dynamic 2- and 3-digit forecast hour formats in post filenames

* Use "print_err_msg_exit" if forecast hour length is too long or short.

* Fix indentations

* Remove 0 from dynf0#fhr# and phyf0#fhr# dependencies for post task in XML template
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jiandewang jiandewang

Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@aerorahul @jiandewang @JessicaMeixner-NOAA