hash, number, time, lat, lon and geodepth are output as blob diagnostics automatically. But, if they are listed in the blob diagnostic table, a warning is raised that they are unrecognised variables.

Instead of 1.6.5-mlx this should be 1.8.2

Add a 1/4 degree tests case to the list of supported test cases.

The include paths for the ACCESS builds is incorrect and will pick up the wrong compiled lib_ocean files if they exist.

Build changes and hooks to make it possible to unit test particular subroutines based on inputs and outputs.

The MOM run tests can report success when they have failed. The tests need to be improved to check for success/failure more thoroughly.

There is a bug in drivers/ocean_solo.F90 which causes a model abort when restarting from Feb of a leap year.

Code below when ALL(restart_interval == 0) and Time end is 29 th of Feb it will try to increment date to 29th Feb of a non leap year and then abort.

if(ALL(restart_interval ==0)) then
Time_restart = increment_date(Time_end, 1, 0, 0, 0, 0, 0)
else
Time_restart = increment_date(Time_restart_init, restart_interval(1), restart_interval(2), &
restart_interval(3), restart_interval(4), restart_interval(5), restart_interval(6) )
if(Time_restart <= Time_start) call mpp_error(FATAL, &
'==>Error from program ocean_solo: The first intermediate restart time is no larger than the start time')
end if

The ESM2M_pi-control_C2 fails with floating invalid in mg_drag, suspect this is due to unusual where statement behaviour.

Presently the testing infrastructure runs the tests cases one after the other. It would be a lot quicker to do these in parallel.

For example there is code like:

ierr = check_nml_error(io_status,'ocean_vert_kpp_mom4p1_nml')

and

ierr = check_nml_error(io_status,'ocean_vert_kpp_mom4p1_nml')

but no following check that ierr does not indicate an error. This means that a typo within a namelist would result in default parameters being silently used. Model output will be incorrect without the user knowing.

An email from Russ:

Further to yesterday's chat here is the way I redid the coupling from the mom side of things

The original loop was

do nc=1, num_cpld_calls
get_bcs_from_ice
step_the_ocean
send_ocean_sfc_to_ice
end

I changed this to:

do nc=1, num_cpld_calls
get_bcs_from_ice
if (nc /= 1 ) send_ocean_sfc_to_ice
step_the_ocean
end
send_ocean_to_ice

In the ice code

do nc
send_to_ocean
step
get_from_ocean
enddo

to

do nc
send_to_ocean
if(nc /= 1) get_from_ocean
step_the_ice
end
get_from_ocean

So the ice boundary is sent twice (step 1 and 2) before the ocean BCs are first sent we then have to send the ocean BCs a final time at the end of the loop.

There is a line like:

-L$(OASIS_ROOT)/lib -lpsmile.MPI1 -lmct -lmpeu -lscrip

In the mkmf for nci.

This will prevent the executable from being created if the libraries are not found.

Valgrind is a very powerful tool for finding memory bugs (array overruns, using uninitialised values, reading or writing to/from unallocated memory). This issue introduces automated tests that run all MOM test cases using valgrind.

Hi Hailin, thanks a lot for this. I'll merge it now.

I'd like to make an issue to clean up some of this code at a later date. I'd mostly like to make cosmetic changes, e.g.:

use #if defined(ACCESS)

remove comments like ! <some date ... version control takes care of this so no need to have these.

remove code which is commented out. It's just messy, can always checkout an earlier copy if you want to see old code.

improve some comments so that they are easier to understand.

I'll get you to review any changes I make as part of the clean-up issue just to make sure I'm not messing things up. Does that sound OK?

From Russ Fiedler:

Hi,

Note: This bug will only affect results when using the anisotropic option for friction.

A bug seems to have crept into the biharmonic friction module in attempts to optimise the code and reducing the number of MPI messages made.

There are 2 2d arrays sin2theta and and cos2theta which were calculated as temporary arrays for each level when
domain updates were done at each level. Now that the updates are done all at once for all depths the second half of the calculation is using the last values of these arrays calculated. i.e. those at the bottom of the ocean.

To make clear the old style looping (mom4p1) was like

do k
do i,j
calc sin2theta on this level
calc stresses using sin2theta
enddo i,j
update domains, calculate laplacian
do i,j
complete second half of stress calculation reusing sin2theta ! Still valid
enddo i,j
compute biharmonic
enddo k

The new code procedes as

do k
do i,j
calc sin2theta on this level
calc stresses using sin2theta
enddo i,j
enddo k
update domains, calculate laplacian on every level
do k
do i,j
complete second half of stress calculation reusing sin2theta (! not recomputed)
enddo i,j
enddo k
compute biharmonic for all levels

The solution would be to calculate sin2theta and cos2theta as 3D arrays or just recompute the values and only have them as scalars.

Fujitsu compilers seem to have the same problem as GCC with upcasting boolean arrays as integers (or maybe vice versa).

In any case, file src/shared/oda_tools/oda_types.F90 will not compile under Fujitsu compilers unless we use the same exception as used by GCC. So a __FUJITSU preprocess variable check is also required in line 85.

The ARC CSS (https://www.climatescience.org.au/) has provided storage space to host test case input data. Use this.

In fms_io.F90, MOM will provide a generic warning if there is any nonzero IO status from opening an namelist without providing the specifc error code, even though the error code is saved to io_status.

This should be modified to also provide the error code, or just remove the error entirely and rely on Fortran runtime.

MOM_solo build tests are being done but there are no run tests. Add these. THey are:

box1, box_channel1, bowl1, dome1, gyre1, iom1, mk3p51, symmetric_box1, torus1, dome_bates_blobs1

We removed git annex from the repo (perhaps prematurely) we now need to find a replacement for data file versioning.

Suggest something simple for the time being such as a data_sources.txt file that specifies the data source URL for a particular data input. This will also simplify the get_exp_data.py script.

Add md5sum check to data download script:

https://github.com/BreakawayLabs/mom/blob/7511f4b964f3a28af6ecc2b3e132a95dc18fa714/data/get_exp_data.py

The md5sums are in the same directory as the data, named same as the datafile with a .md5 appended.
e,g.

-rw-rw----+ 1 nah599 ua8 524743 Jan 22 2015 torus1.output.tar.gz
-rw-r-----+ 1 aph502 ua8 55 Sep 11 09:14 torus1.output.tar.gz.md5

Should be possible to try downloading an .md5, if successful, run md5sum -c md5file

I guess not everyone will have md5sum in their path, but warn them that they should install as data integrity cannot be guaranteed?

Thanks

Aidan

The min S can go negative near, e.g. Rio de Plata, occasionally. This doesn't look like numerical instability and doesn't go away with a lower timestep.

The minimum S is 4.746731046187E-02 psu at (i,j,k) = ( 897, 347, 1), (lon,lat,dpt) = ( -55.8750, -35.3843, 5.0335 m)
The minimum S is -9.460506569319E-02 psu at (i,j,k) = ( 897, 347, 3), (lon,lat,dpt) = ( -55.8750, -35.3843, 25.2194 m)
The minimum S is -2.842612159931E-01 psu at (i,j,k) = ( 897, 347, 1), (lon,lat,dpt) = ( -55.8750, -35.3843, 5.0335 m)
The minimum S is -4.255482755701E-01 psu at (i,j,k) = ( 897, 347, 1), (lon,lat,dpt) = ( -55.8750, -35.3843, 5.0335 m)
The minimum S is -3.992160389502E-01 psu at (i,j,k) = ( 897, 347, 2), (lon,lat,dpt) = ( -55.8750, -35.3843, 15.1006 m)
The minimum S is -3.261900299750E-01 psu at (i,j,k) = ( 897, 347, 3), (lon,lat,dpt) = ( -55.8750, -35.3843, 25.2194 m)
The minimum S is -2.954316267829E-01 psu at (i,j,k) = ( 897, 347, 4), (lon,lat,dpt) = ( -55.8750, -35.3843, 35.3585 m)
The minimum S is -2.671503405474E-01 psu at (i,j,k) = ( 897, 347, 3), (lon,lat,dpt) = ( -55.8750, -35.3843, 25.2194 m)
The minimum S is -1.675075110457E-01 psu at (i,j,k) = ( 897, 347, 4), (lon,lat,dpt) = ( -55.8750, -35.3843, 35.3585 m)
The minimum S is 3.083211961732E-02 psu at (i,j,k) = ( 897, 347, 4), (lon,lat,dpt) = ( -55.8750, -35.3843, 35.3585 m)
The minimum S is 3.156939970899E-01 psu at (i,j,k) = ( 897, 347, 4), (lon,lat,dpt) = ( -55.8750, -35.3843, 35.3585 m)
The minimum S is 7.476128076027E-01 psu at (i,j,k) = ( 897, 347, 4), (lon,lat,dpt) = ( -55.8750, -35.3843, 35.3585 m)

Line 902 of src/mom5/ocean_param/lateral/ocean_mixdownslope.F90 reads
wrk1(i,j,k) = tend_mix(i,j,k)*mixdownslope_mask(i,j)

In fact it should read
wrk1(i,j,k) = tend_mix(i,j,k)_mixdownslope_mask(i,j)_T_prog(nt)%conversion

This bug only affects diagnostic budgets for the contribution of mixdownslope. The prognostic budgets are fine.

Stephen Griffies

The following command does not work:

./MOM_compile.csh --platform ubuntu --type EBM

Possibilities:

• Aarnet cloudstor+
• NCI cloud

The ACCESS model types change lib_ocean. This library should use a separate build area for each type.

Excerpts from email exchange pasted below.

Sure! I would be delighted to see it remedied. I have no idea why the public version has an orographyless atmosphere.

As explained in the thread below, the files for the configuration I have been using are available here:

http://earth.cs.mcgill.ca/mom5_fv.tar
http://earth.cs.mcgill.ca/CM2Mc.boundaryFiles.tar
http://earth.cs.mcgill.ca/fms.tar
http://earth.cs.mcgill.ca/siena_blingv2_y1_131014.cpio
http://earth.cs.mcgill.ca/CM2Mc_v1p5_control

The initial conditions (siena_blingv2_y1_131014.cpio) are the important thing, since they include the orography, though there may be an incompatibility with variable names in BLING (and possibly other things) depending what has happened to the code since Siena.

I am not sure what the best way to get these incorporated in the public release would be - let me know what you think.

A quick note to say that I found this discussion thread, and the files provided by Eric, particularly useful. I would like to echo Elizabeth's comments that the CM2M_coarse_BLING test case has no orography included for the atmosphere component of the model. In fact, the CM2M_coarse_BLING test case has no atmospheric restart files included.

For new users of the model whose primary interest is in the ocean, this can be a bit confusing, because the model seems to work as is, but it defaults to a cold start of the atmosphere with no mountains.

mppnccombine fails on this test case with the following error:

Error: different number of records than the first input file!
Warning: output file may be incomplete!

Here is the command that I executed:

[nah599@r746 RESTART]$ /short/v45/nah599/more_home/MOM5/bin/mppnccombine.nci icebergs.res.nc icebergs.res.nc.0000 icebergs.res.nc.0001 icebergs.res.nc.0002 icebergs.res.nc.0003 icebergs.res.nc.0004 icebergs.res.nc.0005 icebergs.res.nc.0006 icebergs.res.nc.0007 icebergs.res.nc.0008 icebergs.res.nc.0009 icebergs.res.nc.0010 icebergs.res.nc.0011 icebergs.res.nc.0012 icebergs.res.nc.0013 icebergs.res.nc.0014 icebergs.res.nc.0016 icebergs.res.nc.0017 icebergs.res.nc.0018 icebergs.res.nc.0019 icebergs.res.nc.0020 icebergs.res.nc.0021 icebergs.res.nc.0023 icebergs.res.nc.0024 icebergs.res.nc.0025 icebergs.res.nc.0026 icebergs.res.nc.0027 icebergs.res.nc.0028

See https://climate-cms.nci.org.au/jenkins/job/mom-ocean.org/job/MOM5_compile/

This would be useful for keeping track of the code used to build a certain executable. This is general functionality and could be done within FMS. There are some useful explanations here:

http://stackoverflow.com/questions/1704907/how-can-i-get-my-c-code-to-automatically-print-out-its-git-version-hash

http://stackoverflow.com/questions/15141338/embed-git-commit-hash-in-a-net-dll

http://stackoverflow.com/questions/6526451/how-to-include-git-commit-number-into-a-c-executable

These test cases fail when using a debug build with the following error:

Image PC Routine Line Source
fms_MOM_SIS.x 000000000933D110 Unknown Unknown Unknown
fms_MOM_SIS.x 0000000008184297 diag_manager_mod_ 1658 diag_manager.F90
fms_MOM_SIS.x 000000000813281C diag_manager_mod_ 1053 diag_manager.F90
fms_MOM_SIS.x 0000000001D7ED76 ocean_util_mod_mp 1027 ocean_util.F90
fms_MOM_SIS.x 00000000069DA8E5 ocmip2_abiotic_mo 1216 ocmip2_abiotic.F90
fms_MOM_SIS.x 0000000002D08FE7 ocean_tpm_mod_mp_ 1520 ocean_tpm.F90
fms_MOM_SIS.x 00000000005976D8 ocean_model_mod_m 1624 ocean_model.F90
fms_MOM_SIS.x 0000000000538041 MAIN__ 694 coupler_main.F90
fms_MOM_SIS.x 000000000040C88E Unknown Unknown Unknown
libc.so.6 00002AE0CEAB2D5D Unknown Unknown Unknown
fms_MOM_SIS.x 000000000040C799 Unknown Unknown Unknown
forrtl: severe (408): fort: (2): Subscript #1 of the array BUFFER has value 61 which is greater than the upper bound of 60

There is a minor bug in the vorticity diagnostic. The bug has no impact on the prognostic solution.

The bug appears on line 1116 of mom5/ocean_diag/ocean_velocity_diag.F90. The bug concerns the indices for dyter.

Rather than dyter(i,j-1), the indices should be dyter(i-1,j).

The bug has no impact for uniform grids. It has only a minor impact for general grids.

Stephen Griffies

There are still an outdated call to write_version_number in coupler_main.F90 (incorrect signature) which stops MOM_SIS building:

src/coupler/coupler_main.F90:830

call write_version_number(version, tag)

The are also still a few more in the source tree:

https://github.com/BreakawayLabs/mom/search?utf8=✓&q=write_version_number+version+tag&type=Code

A few of the modules (ice_sis and ocean_blobs) use NCGLOBAL to define global attributes, but it looks like this is not defined in netcdf-fortran 4.4.

I'm not sure if NCGLOBAL was defined in older version of netcdf-fortran, or if they were inheriting the netcdf.h C library; I know that there was a more explicit separation of the C and Fortran codes recently, which may be why I am only seeing this on the newest version (netcdf 4.3.2, netcdf-fortran 4.4.1).

Anyway, I think these need to be replaced with nf_global. (Works for me, at least)

If I am using one of the coupler-based drivers (e.g.MOM_SIS) and my input.nml only has the ocean enabled, e.g.:

&coupler_nml
    ! ...
    do_atmos = .false.
    do_land = .false.
    do_ice = .false.
    do_ocean = .true.
    ! ...
/

then the model will crash with a segfault, and no indication of the problem. I think some sort of error message is necessary in this case.

Here is the summary:
Subroutine: horz_advection_centered
File: mom-5.1.0/src/mom5/ocean_core/ocean_velocity_advect.F90
Line 410
Code: (tmp2(i,j)-tmp2(i,j-1))*Grd%dytnr(i,j)
Description: C-grid calculation of y-advection of u-component uses grid step denominator dytn, while the correct step is dyte.

For example:

&ocean_vert_mix_nml
vert_mix_scheme='kpp_mom4p1'
/

and

&ocean_vert_kpp_mom4p1_nml
use_this_module=.false.
/

Does not result in an error. If this is not picked up by the user then the model will run with incorrect settings.

The run tests, e.g. https://climate-cms.nci.org.au/jenkins/job/mom-ocean.org/job/MOM_run/ only dump the stdout/stderr when a test fails. It would be useful to dump output on successful runs also. This will allow users to compare their run output with a successful run output.

When I rebuild MOM, it seems like FMS is getting rebuilt every time, even if there have been no changes to FMS.

I think this is because the sed patch to version.F90 is updating the hash, even if the hash is unchanged.

Is it possible to patch FMS_compile.csh to prevent the sed call when the hash is unchanged?

The ulm FMS release appears to have removed the following namelist variables from fms_io_nml

• threading_write
• fileset_write

They are implemented in the current FMS patch under review (#132) to avoid breaking any existing runs, but are flagged as deprecated. They may need to be reviewed for a later (5.2?) release.

In ocean_density.F90 global variable neutralrho_interval_r is initialized at line 1286, after it is used in compute_diagnostic_factors(...) which is called at line 1159. This causes model to crash when using intel compiler with -g option.

Ping Zhai
Hi,

I just found that the unit of dic_x(y,z)flux_adv(gm, submeso, ...) in *0101.ocean_bling_adv_dic.nc is not right, it should be mole/s instead of kg/s. I calculated the dic transport by multiplying dic concentration with transport, and compared my result with the model output dic_x(y,z)flux_, and found out that the right unit is mole/s.

The unit of dic_advection in ****0101.ocean_bling_term_dic.nc should be mole/m^2/s instead of “kg/m^2/s”. topaz dic also has the same problem.

Best,

Ping

There have been reports that the 0.25 degree test case does not have bit reproducibility across restarts. This issue will create a test for this.

ifort version 15.x.x has been troublesome. We are currently getting a large number of 'floating invalid' exceptions in code that uses the 'where' construct. This does not appear to happen with the new compilers. e..g

     Unknown  Unknown

fms_ICCM.x 0000000003C8B25F Unknown Unknown Unknown
fms_ICCM.x 0000000003C8FE34 Unknown Unknown Unknown
libpthread.so.0 00002AE1EC7547E0 Unknown Unknown Unknown
fms_ICCM.x 0000000003638443 soil_mod_mp_updat 1317 soil.F90
fms_ICCM.x 000000000361BAF2 land_model_mod_mp 721 land_model.F90
fms_ICCM.x 000000000047C120 MAIN__ 598 coupler_main.F90
fms_ICCM.x 000000000040CC6E Unknown Unknown Unknown
libc.so.6 00002AE1EC980D5D Unknown Unknown Unknown
fms_ICCM.x 000000000040CB79 Unknown Unknown Unknown
forrtl: error (65): floating invalid
Image PC Routine Line Source
fms_ICCM.x 0000000003D64D01 Unknown Unknown Unknown
fms_ICCM.x 0000000003D63457 Unknown Unknown Unknown

[vpr561@raijin3 exp]$ ./MOM_run.csh --platform nci --type MOM_SIS --experiment global_0.25_degree_NYF --download_input_data
Traceback (most recent call last):
File "./get_exp_data.py", line 8, in
import argparse
ImportError: No module named argparse
cp: cannot stat `global_0.25_degree_NYF.input.tar.gz': No such file or directory
tar (child): global_0.25_degree_NYF.input.tar.gz: Cannot open: No such file or directory
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now
ERROR: the experiment directory '/short/v45/vpr561/mom/work/global_0.25_degree_NYF/INPUT' does not exist or does not contain input and preprocessing data directories!
Either use the --download_input_data option or copy the input data from the MOM data directory manually.
To manually dowload the data execute the following:
cd /short/v45/vpr561/mom/data
./get_exp_data.py global_0.25_degree_NYF.input.tar.gz
mkdir -p /short/v45/vpr561/mom/work
cp archives/global_0.25_degree_NYF.input.tar.gz /short/v45/vpr561/mom/work
cd /short/v45/vpr561/mom/work
tar zxvf global_0.25_degree_NYF.input.tar.gz
[vpr561@raijin3 exp]$