Glam:testing
The glam respository now contains a test script to provide a quick check for whether code changes impact on model output. This is currently set up
The test script is valid if the following hold:
- The GLAM/knowngood/glam_2d.nc file contains up to date known good velocity fields.
- NC_DIR in the makefile points to a valid netcdf installation for your compiler.
The test script can be run using the makefile as follows:
make test
This will build the executable GLAM/nccompare.exe (from compare.cpp) and run the test script GLAM/test.sh
Further plans:
from Steve:
> ... as noted in previous, I think if you run the test case now it will
> report back a failure (rather than ok). That is because I changed the
> bcs, which should have been periodic (rather than u=v=0). Re-running the
> code now should generate a result that can be used as the 'knowngood' for
> the test case.
Okey doke. You can just overwrite (cp) the file in the GLAM/knowngood dir and commit the change.
Rupert, I can provide Duncan with the tar file to install the Sun compiler on your machine of choice.
Yes, it is nice to end up where we were headed. We do have some significantly better code as a consequence of all our labours, however:)
Cheers, Gethin.
from Steve re test setup:
Rupert, where are we with the test suite? Are we supposed to be adding more variables at some point? I'm not really sure how to proceed with this at the moment. The velocity comparison is (I think) more or less all we need for testing the 'dynamics' component of the model. We could add a comparison of various stress components, but I'm not too worried about that at the moment (if they were off, the velocities would be off, or vice versa). Other parts to test still are the thermal calc. and the thickness evolution calc. It might be easiest to just set up separate tests altogether for those (e.g. "glam_test2.nml", "glam_test3.nml"), rather than mixing them in w/ the dynamics test. Is this how it is generally done Gethin, or do you have one test that looks at everything? Seems like keeping them separate gives you some better idea of what part of the code a bug might be coming from, if one shows up down the line.
from Steve re netcdf lib locations in makefile:
In the long run, it is probably only necessary to do regular testing of the code on a few machines, in which case the locations of the netcdf libs will remain more-or-less fixed over time.
Currently, however, I've got my netcdf libs in one place, Rupert has then in another, Gethin in another, Athos/Porthos/Aramis cluster somewhere else ...
How about we temporarily add some lines to the makefile like such:
- Path to NetCDF libraries (UOB, GETHINS MACHINES):
- NC_DIR = /opt/local/32/intel_fc_81
- NC_DIR = /opt/local/CentOS-32/netcdf/3.6.0_p1/gnu_fc_gfortran
- NC_DIR = /opt/local/CentOS-32/netcdf/3.6.0_p1/gnu_fc_g95
- NC_DIR = /opt/local/CentOS-32/netcdf/3.6.0_p1/intel_fc_81
- NC_DIR = /opt/local/CentOS-32/netcdf/3.6.0_p1/sun_fc_12
- NC_DIR = /opt/local/gnu_fc_g95
- NC_DIR = /exports/gpfsbig/home/ggdagw/netcdf-pgi
- Path to NetCDF libraries (LANL):
- NC_DIR = /opt/local/gnu_fc_gfortran
- NC_DIR = /opt/local/gnu_fc_g95
- Path to NetCDF libraries (UOB, 3 MUSKS):
<< 3 Musks paths here >>
- Path to NetCDF libraries (UOB, RUPERT):
<< Rupert's paths here >>
...etc.
Perhaps there is something slicker (like if you don't find the libs at location A, look at B, then C, ... etc), but this would work for now.