Version number in netcdf

[mattdturner]

These edits now include the CICE version number (pulled from version.txt) in the netcdf output files.

• Developer(s): Matt Turner

• Please suggest code Pull Request reviewers in the column at right.

• Are the code changes bit for bit, different at roundoff level, or more substantial? bfb

• Is the documentation being updated with this PR? (Y/N) N
  If not, does the documentation need to be updated separately at a later time? (Y/N) N
  Note: "Documentation" includes information on the wiki and .rst files in doc/source/,
  which are used to create the online technical docs at https://readthedocs.org/projects/cice-consortium-cice/.

• Other Relevant Details:
  This addresses version number in netcdf output #82
  The attribute in the netcdf file is currently:
  :source = "Los Alamos Sea Ice Model, CICE_6.0.0.alpha" ;

[apcraig]

The variable VERSION in the source code has to be a valid variable. If a VERSION cpp is not passed to the code, it should still build and run. So, we need something like

character(len=*), parameter :: version_name="VERSIONNAME"

and I would put that in ice_history_shared.F90 for now. Then, the other code changes would be

write(title,'(2a)') 'Los Alamos Sea Ice Model, ', trim(version_name)

and then if a cpp, -DVERSIONNAME=Icepack1.0.2 then it should work and if the cpp is not included, it should also build and run (with undefined version name). Also, this should simplify the complicated quoting in the cpp and I believe that can now be simply -DVERSIONNAME=${ICE_VERSION}

The other problem is that the version is already being partly set/managed in cice.setup. So if a user sets --version in cice.setup, then the version.txt is overwritten. Grabbing ICE_VERSION as line 4 might grab the "old" version instead of the current. We also have a broader issue of managing the version numbers consistently in the project which is outside this update, but could eventually lead to changes later.

[eclare108213]

Question:

if a user sets --version in cice.setup, then the version.txt is overwritten.

Usually, a --version flag only returns what the version number is, doesn't it? Why would version.txt be overwritten?

[apcraig]

This is a good point. The --version feature was added at some point to allow the scripts to update the version via the scripts, rather than have the user have to do it manually. That feature probably needs to be reviewed to make sure it's working as it should, and we can decide whether we want it or not. It's also true that --version may not be the best name. Maybe --version should return the version number and --setversion should set it.

[eclare108213]

Let's have --version return the current version number. I didn't know we had an option to use the scripts to set the version number. Maybe that could be helpful, since we have version numbers in numerous places.

[apcraig]

It might also be good to implement the CICE version not as a cpp but as a namelist input. Generally, cpps should be avoided except for this that have to be defined at compile time. The version name is not one of those things.

[apcraig]

@mattdturner , I would not worry about the --version argument at this point. I'll fix that when we make some progress on version naming process.

[mattdturner]

Ok, I updated the Pull Request to remove the CPP flag for version and replace it with a version_name variable in the setup_nml namelist. version_name is defined in ice_history_shared.F90, and assigned a default value.

[apcraig]

Should we change "Los Alamos Sea Ice Model" to "CICE-Consortium Sea Ice Model" ?

[eclare108213]

My preference is to leave it as it is. Considerations: (1) "Los Alamos Sea Ice Model, CICE" is the official, legal name of the model. (2) The Consortium might eventually have more than one sea ice model. (3) Some people have turned CICE into the acronym for Community Ice CodE, but I never adopted that, partly for funding-agency (DOE) reasons and partly because I'm just not that fond of it.

I'm open to other suggestions, but perhaps this should be discussed in a separate issue rather than this PR.

[apcraig]

@eclare108213 that's reasonable. lets defer question of Los Alamos naming convention and leave for now.