# Setting build options for OM3 **URL:** \ **Category:** Regional MOM6\ **Tags:** spack\ **Created:** [23 April 2025 04:25 UTC](https://forum.access-hive.org.au/t/setting-build-options-for-om3/4495 "2025-04-23T04:25:02Z")\ **Posts on this page:** 1\ **Showing post:** 44
**Author:** ![Paul.Gregory](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/paul.gregory/32/2566_2.png) [@Paul.Gregory](https://forum.access-hive.org.au/u/Paul.Gregory)\ **Post date:** [1 August 2025 06:44 UTC](https://forum.access-hive.org.au/t/setting-build-options-for-om3/4495/44 "2025-08-01T06:44:14Z")
Hi Angus. The quest for a debuggable executable goes back to these tests on a small test domain. > [@ESMF mesh and MOM6 domain masks are inconsistent](https://forum.access-hive.org.au/t/esmf-mesh-and-mom6-domain-masks-are-inconsistent/4380/22): > > Ok just summarising my latest progress. Remember I had trouble running @Helen’s original configuration (140 x 249 Tasmanian domain at 0.05 resolution requesting 100 CPUs on a 10x10 layout) so I attempted to incrementally change @mmr 's original config (70x125 at 0.1 with 16 CPUs on a 4x4) I’ve been able to run @mmr0 's configuration for the following layouts: Layout Runtime 4x4 09:48 8x8 05:12 10x10 04:07 12x12 03:49 All of these worked with no mask table in MOM\_layout I the… I could run a small test case at two resolutions and multiple decompositions, but when I ran with a 10x10 decomposition at 0.05 degree resolution, it generated this error. ```auto FATAL from PE 86: ERROR: ESMF mesh and MOM6 domain masks are inconsistent! - MOM n, maskMesh(n), mask(n) = 306 1 0 FATAL from PE 82: ERROR: ESMF mesh and MOM6 domain masks are inconsistent! - MOM n, maskMesh(n), mask(n) = 81 1 0 ``` I did some tests on the masks here: > [@ESMF mesh and MOM6 domain masks are inconsistent](https://forum.access-hive.org.au/t/esmf-mesh-and-mom6-domain-masks-are-inconsistent/4380/15): > > OK so I copied @mmr0 's configuration : 4x4 decomposition on a domain measuring 70x125 at 0.1 resolution, to another directory and regenerated the default domain : 10x10 decomposition on a domain 140x249 at 0.5 resolution. During the domain decomposition, the notebook generated the following: Running GFDL's FRE Tools. The following information is all printed by the FRE tools themselves NOTE from make\_solo\_mosaic: there are 0 contacts (align-contact) congradulation: You have successfully ru… I’ve just run some tests to ensure the bathymetry exists for every grid point outside of the land (i.e. no NaNs in the ocean). ```python bathymetry = xr.open_dataset(f'{input_dir}/bathymetry.nc') bathymetry_grid = xr.DataArray(bathymetry.depth.values.reshape(249,140), dims=['ny','nx'], coords={'ny':ocean_mask.ny, 'nx':ocean_mask.nx}) (bathymetry_grid.isnull() & ESMF_mask.astype(bool)).sum() ``` The sum of this quantity is zero. The bathymetry is consistent with the mask. ![bathymetry_mask](https://us1.discourse-cdn.com/flex020/uploads/access1/original/2X/8/8b89fab12ef8165bfc81e46803701f33c3ceac39.png) If I set `bathymetry_grid[100,101]=np.nan` the sum is non-zero. ![bathymetry_mask_test_nan](https://us1.discourse-cdn.com/flex020/uploads/access1/original/2X/1/18e7df466cf420ab62c40194987c3426a40fdeb8.png) Anyway, I still generate that inconsistent mask error using an older executable. But if I run the same configuration with the debug executable, I generate the error stated above, i.e. ```auto forrtl: error (65): floating invalid Image PC Routine Line Source libpthread-2.28.s 0000149D19D07990 Unknown Unknown Unknown access-om3-MOM6-C 00000000010E58EF limit_topography 422 MOM_shared_initialization.F90 ``` So the plan was create an OM3 executable with debug flags to try and understand the interaction between MOM6 and NUOPCY better. If this isn’t possible, we may have to revert to good ‘ol print statements and ASCII output files. --- _[View the full topic](https://forum.access-hive.org.au/t/setting-build-options-for-om3/4495)._