# Issues with regional MOM6 when using 1-degree resolution ocean forcing data **URL:** \ **Category:** ANCOMS\ **Created:** [30 May 2025 00:01 UTC](https://forum.access-hive.org.au/t/issues-with-regional-mom6-when-using-1-degree-resolution-ocean-forcing-data/4565 "2025-05-30T00:01:12Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Lizzie](https://avatars.discourse-cdn.com/v4/letter/l/da6949/32.png) [@Lizzie](https://forum.access-hive.org.au/u/Lizzie)\ **Post date:** [30 May 2025 00:01 UTC](https://forum.access-hive.org.au/t/issues-with-regional-mom6-when-using-1-degree-resolution-ocean-forcing-data/4565/1 "2025-05-30T00:01:12Z")
I’ve been trying to generate forcing data using 1° monthly ACCESS-OM2 output, whereas the examples I’ve seen use 0.1° daily data. I’ve run into two issues so far: 1. I use the monthly data to create access\_om2\_input, and from this the boundary forcing files (north/south/east/west\_unprocessed.nc). When these files are passed to `expt.setup_ocean_state_boundaries` (the updated version of `expt.rectangular_boundaries` in the example recipes), the function assumes the input is daily data. The boundary forcing files it generates don’t cover the full time period I expected them to, (two years of monthly data is misinterpreted as just 24 days). I don’t know if the forcing data has to be daily, or if monthly would be fine as long as it was dated correctly in the files generated! I could get around this by adding this code in before the north/south/east/west\_unprocessed.nc files are saved. ```auto daily_time = pd.date_range(start=date_range[0], end= date_range[1], freq='D') def interp_to_daily(ds): return ds.interp(time=daily_time) ## Cut out East & West boundary conditions and save to netCDF print('East & West boundary condition...') east = rmom6.longitude_slicer(access_om2_input, [longitude_extent[1] - buffer, longitude_extent[1] + buffer], ["xu_ocean", "xt_ocean"]) interp_to_daily(east).to_netcdf(tmp_dir + "/east_unprocessed.nc") ``` 1. The ACCESS-OM2 data I used has 50 vertical levels (nz=50), but in `rmom6.experiment` I had set `number_vertical_layers = 75`. `Expt.setup_initial_condition()` handled the vertical regridding correctly, and the resulting initial condition files had nz=75 as expected. `Expt.setup_ocean_state_boundaries` produced boundary forcing files that still only had nz=50. Again I could get around this by adding something like this into the notebook before calling `Expt.setup_ocean_state_boundaries` ```auto rg_output_dir = tmp_dir+"/regrid/" os.makedirs(rg_output_dir, exist_ok=True) zl_interp = expt.vgrid.zl.rename({'zl': 'st_ocean'}) directions = ["north", "south", "east", "west"] for direction in directions: input_file = os.path.join(tmp_dir, f"{direction}_unprocessed.nc") output_file = os.path.join(rg_output_dir, f"{direction}_unprocessed.nc") print(f"Interpolating {input_file}") ds = xr.open_dataset(input_file) ds_interp = ds.interp({'st_ocean': zl_interp}) ds_interp.to_netcdf(output_file) print(f"Saved to {output_file}") ``` and using `rg_output_dir` as the inputput for `exp.setup_ocean_state_boundaries(raw_boundaries_path=Path(rg_output_dir))` ---
**Author:** ![dougiesquire](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/dougiesquire/32/16_2.png) [@dougiesquire](https://forum.access-hive.org.au/u/dougiesquire)\ **Post date:** [30 May 2025 03:21 UTC](https://forum.access-hive.org.au/t/issues-with-regional-mom6-when-using-1-degree-resolution-ocean-forcing-data/4565/2 "2025-05-30T03:21:44Z")
Thanks for posting @Lizzie. Are you hoping to get help from ACCESS-NRI with this? Adding the #help tag to your post will mean it gets triaged by our support team. See [Support FAQ (Frequently Asked Questions)](https://forum.access-hive.org.au/t/support-faq-frequently-asked-questions/1021) ---
**Author:** ![mmr0](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/mmr0/32/2485_2.png) [@mmr0](https://forum.access-hive.org.au/u/mmr0)\ **Post date:** [30 May 2025 05:31 UTC](https://forum.access-hive.org.au/t/issues-with-regional-mom6-when-using-1-degree-resolution-ocean-forcing-data/4565/3 "2025-05-30T05:31:24Z")
Hey Lizzie, I can’t really help except to say that I noticed the same thing about the boundary files still having the native vertical resolution of the forcing dataset. I think the interpolation might be handled by MOM6 although I’m not totally sure. For your first question - if you don’t have any luck here you could try an issue on the regional-mom6 repo. I’m interested in the answer since I have just discovered that very few of the ACCESS-OM2 models save daily u, v, temp, salt, and ssh. I don’t know if i just suck at using intake, but as far as I can tell only `01deg_jra55v13_ryf9091` and `01deg_jra55v150_iaf_cycle1` have all the variables that regional-mom6 wants - and maybe they only have daily SSH in January? ---
**Author:** ![helen](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/helen/32/2840_2.png) [@helen](https://forum.access-hive.org.au/u/helen)\ **Post date:** [12 June 2025 11:32 UTC](https://forum.access-hive.org.au/t/issues-with-regional-mom6-when-using-1-degree-resolution-ocean-forcing-data/4565/4 "2025-06-12T11:32:43Z")
> [@Lizzie](#): > > I use the monthly data to create access\_om2\_input, and from this the boundary forcing files (north/south/east/west\_unprocessed.nc). When these files are passed to `expt.setup_ocean_state_boundaries` (the updated version of `expt.rectangular_boundaries` in the example recipes), the function assumes the input is daily data. The boundary forcing files it generates don’t cover the full time period I expected them to, (two years of monthly data is misinterpreted as just 24 days). I don’t know if the forcing data has to be daily, or if monthly would be fine as long as it was dated correctly in the files generated! Thanks for bringing this up @Lizzie! I would really appreciate it if you could raise it as an issue in the [GitHub repository](https://github.com/COSIMA/regional-mom6/issues/new). All the testing has been done on Glorys data which is daily so would be very easy for this bug to be missed. ---
**Author:** ![helen](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/helen/32/2840_2.png) [@helen](https://forum.access-hive.org.au/u/helen)\ **Post date:** [12 June 2025 11:33 UTC](https://forum.access-hive.org.au/t/issues-with-regional-mom6-when-using-1-degree-resolution-ocean-forcing-data/4565/5 "2025-06-12T11:33:39Z")
> [@mmr0](#): > > I can’t really help except to say that I noticed the same thing about the boundary files still having the native vertical resolution of the forcing dataset. I think the interpolation might be handled by MOM6 although I’m not totally sure. I thought it was as well - but perhaps someone like @ashjbarnes could pipe in to confirm? ---
**Author:** ![helen](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/helen/32/2840_2.png) [@helen](https://forum.access-hive.org.au/u/helen)\ **Post date:** [12 June 2025 11:38 UTC](https://forum.access-hive.org.au/t/issues-with-regional-mom6-when-using-1-degree-resolution-ocean-forcing-data/4565/6 "2025-06-12T11:38:24Z")
> [@mmr0](#): > > I’m interested in the answer since I have just discovered that very few of the ACCESS-OM2 models save daily u, v, temp, salt, and ssh. I think this issue warrants a larger discussion. For regional modelling, we tend to use daily or higher frequency forcing so I think the lack of ACCESS-OM2 models with daily outputs will become an issue for a lot of regional mom6 users. Is there any energy for a discussion about how we might set up a model run with higher frequency outputs? ---
**Author:** ![angus-g](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/angus-g/32/89_2.png) [@angus-g](https://forum.access-hive.org.au/u/angus-g)\ **Post date:** [13 June 2025 00:14 UTC](https://forum.access-hive.org.au/t/issues-with-regional-mom6-when-using-1-degree-resolution-ocean-forcing-data/4565/7 "2025-06-13T00:14:50Z")
Yes, the OBC code uses the remapping core to go from whatever the segment grid is to the model grid. ---
**Author:** ![ashjbarnes](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/ashjbarnes/32/205_2.png) [@ashjbarnes](https://forum.access-hive.org.au/u/ashjbarnes)\ **Post date:** [13 June 2025 03:18 UTC](https://forum.access-hive.org.au/t/issues-with-regional-mom6-when-using-1-degree-resolution-ocean-forcing-data/4565/8 "2025-06-13T03:18:03Z")
Yeah the OBCs don’t need to be regrided vertically - MOM6 does this online thankfully so you don’t have to have extra big boundary files to match your model’s (presumably finer) vertical grid. Regarding the time dimension: the boundary class does have the option to specify the [time units](https://github.com/COSIMA/regional-mom6/blob/92cbcd1d6d2db030ce40e08a03eba0c09d2d6b57/regional_mom6/regional_mom6.py#L2612) of the boundaries, however this hasn’t been implemented in the wrapper method [setup\_ocean\_state\_boundaries](https://github.com/COSIMA/regional-mom6/blob/92cbcd1d6d2db030ce40e08a03eba0c09d2d6b57/regional_mom6/regional_mom6.py#L1431) which we use in the demo. For context, users used to have to call the segment class for each segment (and still do if they want to do more complex things with their boundaries). But we decided to wrap this up in one function to keep the demo notebook streamlined and easier for beginners. But clearly we forgot to include some edge cases! An easy fix is just to add a key word argument to the ocean state boundaries function, which passes the time units onto the [boundary segment class](https://github.com/COSIMA/regional-mom6/blob/92cbcd1d6d2db030ce40e08a03eba0c09d2d6b57/regional_mom6/regional_mom6.py#L2581) on initialisation. @Lizzie would you have time to do this as a quick PR? To fix the data you’ve already made, you just need to modify the metadata to correct the time units. At the end of the day that’s all that rmom6 does: writes the [appropriate time encoding into the netcdf file](https://github.com/COSIMA/regional-mom6/blob/92cbcd1d6d2db030ce40e08a03eba0c09d2d6b57/regional_mom6/regional_mom6.py#L2877-L2880) before saving it. ---
**Author:** ![mmr0](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/mmr0/32/2485_2.png) [@mmr0](https://forum.access-hive.org.au/u/mmr0)\ **Post date:** [14 June 2025 02:28 UTC](https://forum.access-hive.org.au/t/issues-with-regional-mom6-when-using-1-degree-resolution-ocean-forcing-data/4565/9 "2025-06-14T02:28:52Z")
Hi Helen - definitely appetite from me for this discussion. @PSpence may want to join too. It would be great if the re-run included more recent years!