-
Notifications
You must be signed in to change notification settings - Fork 11
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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.
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
Setting up Regional-MOM6 on non-NCI system #79
Comments
Okay, downgrading to motu-client v1.8.0... The warning is self-explanatory and not an issue for now but might be something to keep in mind for future revision. Then an SSL 1006 error crops up before download can start. Trying to dig into that it looks like the motuclient call tries to access a service called GLOBAL_MULTIYEAR_PHY_001_030-TDS (bolded in code snippet below, user account and password deleted from snippet but present in file): But manually opening https://my.cmems-du.eu/motu-web/Motu doesn't show such a service as being available: -Chris |
Getting the same error/outcome when using the API request motu-client code snippet on https://data.marine.copernicus.eu/product/GLOBAL_MULTIYEAR_PHY_001_030/download?dataset=cmems_mod_glo_phy_my_0.083_P1D-m_202112, and downloading data manually seems to also not be working... So, I suspect that's a problem at CMEMS's end... |
Okay, contacted CMEMS and their advice that access via MOTU is no longer stable they would encourage a move to their new Copernicus Marine Client:
|
cc @ashjbarnes |
Hi @croachutas so sorry for the late reply! I'd messed up my Github notification settings so didn't see until Navid tagged me.
I'll make this a priority, since I agree it's really important to be able to onboard new users with an easy example, even if the downloading of data does sit a bit outside of the scope of the package. (since we expect end users to BYO whatever ocean forcing data they want once they've learned how to use the package) If I can help further we can continue the conversation here, or have a zoom call to speed things along :) |
In PR #83 I've removed references to NCI and replaced the Motu client with instructions on how to use the GUI to reproduce the same results. This will be annoying as you'll need to download locally then upload them to your HPC but will have to do for now until we implement their new data API |
Hey, Edit: Below is based upon grabbing an updated version fo the jupyter notebook but without pulling down the full declutter_notebook branch. I've finally got back onto this. Downloaded the updated notebook, copied ERA5 from NCI to my workstation and pulled down two months of GLORYS. So, status at the moment is things run up to step 6 (running FRE tools) where I get the following error:
So, what in the scheme of things looks like a fairly minor problem: Combining a string with a PosixPath should use / rather than + when adding commandline buhmp to the tool path before running a subprocess. So, question is, is that something that needs to be changed in regional_mom6.py, or in line with the older version of the notebook do I need to define the various paths as strings rather than PosixPaths? (Or is it something that's already been fixed but I'll need to update my build of regional-mom6?) Edit: Switching to strings in place of PosixPaths worked fine. |
And witha bit of copy pasting from the older version of the notebook got the full setup done. Now to run a first test... |
Okay, moved over fully to the declutter_notebook branch. Forcing prep runs properly, had to edit MOM_input to specify correct number of layers (NK, was defaulting to 100, reduced it to 30) and diag_table to insert experiment name and start date. Had some initial problems with running via mpirun, but that looks to have been a bugger up on my behalf (running within a conda environment, so just deactivated conda...) but that's resolved. Issues with errors to do with "Invalid variable type in NetCDF file, turns otu i needed to remove the time variable from the initial condition files (Done). Now having issues finding /INPUT/forcing/tu_001.nc etc. which appears to be related to tides.... Commented them out of the OBC_SEGMENT_00[1-4]_DATA file paths specified in MOM_input and set tides to false everywhere I could finda reference to tides, and now having problems with errors like "FATAL from PE 1: Values needed for OBC segment" |
Ohh thanks yeah I'd accidentally left tides in from the run I was using to troubleshoot. If you set
and remove the tidal files from the obc segment files so they all look like:
that will hopefully do it |
For reference here's a MOM_input file for a no tide run |
Thanks, that gets me past that issue but now I'm getting errors about "MOM_diag_remap, initialize_regridding: Specified file not found: Looking for 'INPUT/diag_rho2.nc' (FILE:diag_rho2.nc,interfaces=rho2)" It looks like either diag_rho2.nc isn't being generated when the forcing fields are created or needs to be provided "pre-baked". |
Switched to using DIAG_COORD_DEF_RHO2 = "WOA09" in MOM6_input, might not be ideal but moves me onward for now. Now getting an error about " Unable to find variable DAYMAX in any input files." Edit: Adding DAYMAX following other MOM6 examples sees the model start running but immediately crash because it looks for forcing from outside the time-period provided (defaults to date of 0001-01-01 vs date range on forcing data of 2013-01-01 to 2013-01-10). Comments in MOM6_input in examples suggest it should be possible to set end date via "ocean_solo_nml in input.nml" but I can't seem to find examples that actually do this. Edit 2: As far as I understand this should be read from &coupler_nml in input,nml but isn't for some reason. Edit 3: I built MOM6 following the instructions at https://github.com/mom-ocean/MOM6/blob/main/ac/README.md which seem to be for an ocean only installation... Looks like the setup shown here is instead built with coupling but then uses the coupling code to just feed in surface properties. Will try rebuilding MOM6 following the instructions for allowing coupling at https://github.com/NOAA-GFDL/MOM6-examples/wiki/Getting-started#compiling-the-models |
Oh yeah this would be the problem! Ocean only has no atmospheric forcing and so there's no coupler. The To be able to use the provided input configurations from the demos you'll need an ocean-sis executable. You can use my executable that's ready to go on gadi for testing purposes if you like. It's found at:
|
Thanks good feedback - this probably shouldn't be included actually as it's a diagnostic I've been using for my research. I'll remove it from the demos |
Thanks Ash, Bad temperatures (dimension 1): Which per chasing up in other peoples' error reports suggests something is wonky with atmospheric temperature (temp outside range of the lookup tables used to compute .saturation vapour pressure). Checked the forcing file and it gave 2m temp in degK, thought that might be it, so manually converted the file to degC and still getting same error. Any ideas? |
My apologies Chris. I'll prioritise this and hopefully figure things out this week! I'm now hitting these kinds of errors with my own research too. A couple of things have changed since things were working smoothly with ERA5 in December, notably the mom executable had been out of date so there are possibly some compatibility issues if they patched anything to do with surface forcing. Perhaps in the meantime you could either:
I'll let you know as soon as it's fixed |
Ok Mystery solved. To use ERA5, you need the latest version of FMS as they've updated the surface forcing functionality. Unfortunately, the current MOM_examples uses an FMS version from 3 years ago. My runs were working with ERA5 using an executable that @angus-g had sent me a while ago, but I'd recently recompiled mom6 to include their latest boundary condition improvements, and my FMS version reverted back! I've since fixed the bugs you found on the declutter notebook branch, and I can confirm that with an updated FMS executable the |
Thanks. I'll try pulling down and building the latest version of FMS. |
Angus has a branch of his ninja compile scripts ready to go for the latest FMS and code. On Gadi I've used it already to create a new executable you could use to test. It's found here: |
Thanks again. Downloaded the latest version of FMS and will try building soon. Looking at install instructions and looks like it'll mostly be a matter of changing some paths for some links (hopefully not resulting in things exploding). |
Looks like I've got it working (well, running and not immediately exploding at least). Turns out MOM6_examples provides two versions of FMS (in src/FMS1, 2019ish, and src/FMS2, 2022ish, respectively). By default it builds from src/FMS1... which doesn't work with the coupled model. But changing that to src/FMS2 and wham it's suddenly good. Doing a longer run now to make sure the output isn't doing anything too weird... (I did try building with a new download from the FMS repo but hit errors when compiling the ice-ocean model). |
Interesting! We found we also needed to update the FMScoupler to get it to work. MOM_examples had an older version of this that didn't support surface fluxes at different heights as required by ERA5 forcing |
@croachutas There were issues with the era5 forcing setup: I'd not included the solar fluxes! If you pull down the latest code now (it's all merged into main) then the |
Thanks! Will test later today. |
Okay... Usual minor issues (lack of start date and experiment name in diag_table; need to turn off tides) which can be fixed with a few seconds in relevant config files. Link to input director INPUT no created (just the links names inputdir which always breaks), but that's another easy fix. And the bigger issue, I'm getting a crash with an error "FATAL from PE 1: fms_io_mod(field_size): file INPUT/forcing/tu_001.nc and corresponding distributed file are not found" |
Then missing diag_rho2.nc, in the past replaced that with WOA09 keyword in MOM_input... Done. Would suggest either providing this file for the examples or changing this in the default MOM_input. Now, error because it wants the various forcing files to not have the .nc suffix... Another easy fix at my end, either need to rename the files or change entry in data_table file. Again, something that probably should be changed for the default setup. |
And running now... Three days done and yet to explode, but does seem slower than before you added the surface fluxes (not stupidly slow but may mean I tell the students to do a 5 day run rather than a 10 day run) |
Hmm are you sure you're on the latest version? The diag table and tide issues were fixed. At least if you look at the MOM_input file in the premade run directory the diag table and tides have been removed. The data table in the current version also expects the |
Okay, I see the problem: When installing MOM6_regional to a conda environment I used pip git+https://github.com/COSIMA/regional-mom6.git... Which set up the package in the wrong place, forcing me to manually create the demos folder and subfolders which did not update when I updated the package... Will uninstall and try rebuild using conda-build. |
ok good to know... @angus-g might be able to help. Perhaps the original build instructions need updating with the new demos? Oh and regarding the creation of the It's a good point that we should handle this for non-payu users. Perhaps using the |
Thanks Ash, that seems to have mostly solved the cooling on the seafloor but doesn't look to have helped the cooling of coastal SST as much. |
Yeah that's really strange! I haven't noticed it in my runs which use ERA5, SIS/MOM6 at latest source and Glorys at the boundary. Is your executable fairly up to date? There were some updates to the coupler that helped ERA5 perform more sensibly |
Nope, I'm still using mostly the defaults from the mom6-examples build... Looks like that points to a rather old version of the coupler (coupler @ 14578f0, circa 6 years old). I'm afraid if I try upgrading the coupler it'll break the build scripts as happened when I tried installing more recent versions of FMS. |
(Might need to see if I can get the build using ninja to work... Any idea if that codebase works outside NCI?) |
There's nothing really NCI-specific in it, but you might have to tweak paths. As long as you have working Fortran and C compilers, an MPI implementation and the NetCDF libraries (for C and Fortran), you should be able to get it working. |
Question: should we convert this into a Discussion? If it's not related with a bug/issue in the code I think it fits better into the Discussion section. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Hi,
I'm in the process of setting up Regional-MOM6 on my workstation and working through the reanalysis forcing example as a bit of an exercise to get up to speed on it before using it as a teaching aid for one of the IMAS-OUC 2+2 programme units.
Anyway, I've thus far encountered a few issues:
motu-client isn't listed as a dependency, easy to fix at my end (just pip...) but you probably should add it to the project.toml so this doesn't catch people out in future.
toolpath points to MOM5 tools directory (FRE tools?) instead of tools available with MOM6 or independently:
toolpath = "/home/157/ahg157/repos/mom5/src/tools/"
Again, this is something I can work around (download and build MOM5... Edit: Unclear how to build FRE tools from MOM5 quickstart guide... EDIT AGAIN: Found FRE tools github page, installed apparently successfully), but I think this dependency on MOM5 needs to be clearly stated. Ideally either alternative tools available with MOM6 should be used or the necessary tools should be provided with Regional-MOM6.
Running the code to download GLORY boundary forcing and initial states successfully creates get_oceanfiles.sh but when the code tries to run the shell script I get warnings to the effect of:
/home/croach/anaconda3/envs/MOM6_tools/bin/python: No module named motuclient.__main__; 'motuclient' is a package and cannot be directly executed
and no data is downloaded. Looking at https://github.com/clstoulouse/motu-client-python/tree/master#Usage and comparing that to the contents of get_oceanfiles.sh I suspect that rm.motu_requests is written for motu-client v1.8.0 instead of motu-client v3.x. I can probably downgrade to motu-client v1.8.0 easily enough.Anyway, I'll have a crack at installing the MOM5 tools and downgrading motu-client and keep you updated on if that fixes my current problems.
-Chris Roach
The text was updated successfully, but these errors were encountered: