Command line options interface

[davidorme]

Hi @jedokaplan,

I'm helping out Olivia Haas (@omh20), who is going to use Biome4 as part of her PhD with Colin Prentice and Sandy Harrison. We were using the original code ZIP from PMIP, along with a few changes to parameters. I made some alterations to add command line arguments, mostly to make input file handling a little easier:

https://github.com/ImperialCollegeLondon/biome41

Then I found this repo! The new driver and Makefile are a much better starting point to work with, so I just wanted to ask if you had any interest in a command line interface. We can of course fork this, but I thought I'd ask if it was a feature you were interested in adopting.

I see the interface has changed - the contents of biome4options and biome4outvars files have got much simpler - and I think an interface like this should cover the user options?

Usage: biome4 -c climate.nc -s soils.nc  --co2 410 -o runoutput.nc
Options:
  -h  --help        Print this help screen
Required arguments:
  -c  --climate     Input climate file
  -s  --soils       Input soils file
  -o  --output      Output data file
      --co2       CO2 (ppm)
  -d  --diagnostic  Diagnostic mode  

[jedokaplan]

Hi @davidorme!

Yes that would be great if you wanted to improve the code in this repo directly. I will give you write access to the repo. I like the idea of the command line interface. The only other thing I would add is an optional argument to set the geographic bounds of the model run. I can provide some sample code for this.

[davidorme]

Hi @jedokaplan,

I did mean to include allowing GST coordinate strings at the command line too! I completely forgot to include it. If I read the code right, the new driver automatically uses the extent and resolution of the input file, as opposed to the original hard coded values of -180/180/-60/90 and 0.5°. The limits can currently be overriden using command line argument 2?

I think the best thing to do is for me to create a branch to work on

[jedokaplan]

Sounds good, please go ahead and I we can merge later. I also think I should make a release of the current version before modifications, just as a milestone.

[davidorme]

I've got a prototype of the code but have run into compilation issues. I don't think this is related to the changes I have made - it seems to be missing a netcdf.mod somewhere.

[dorme@login-a BIOME4]$ make
gfortran  -c -o parametersmod.o -I/apps/netcdf/4.5.2-fortran/include parametersmod.f90
gfortran  -c -o netcdfmod.o -I/apps/netcdf/4.5.2-fortran/include netcdfmod.f90
f951: Fatal Error: Reading module ‘netcdf’ at line 1 column 2: Unexpected EOF
compilation terminated.
make: *** [Makefile:41: netcdfmod.o] Error 1

I also haven't quite figured out how to compile the f90getopt.F90 in the makefile. It compiles fine with a standlone gfortran -c f90getopt.F90, which provides the expected f90getopt.mod.

[jedokaplan]

netcdf.mod is either not at the path that you specified in your -I option or there was a problem with the compilation/installation of the netCDF libraries. Make sure you are using the same compiler you used to build netCDF-Fortran to compile BIOME4.

To add f90getopt.F90 to the Makefile just add it to the list of MODELOBJS with the .o suffix. Let me know if this works.

[davidorme]

OK - turned out to be a compiler mismatch. I'm testing using our HPC system, which has a number of available netcdf-fortran builds, and they had built 4.5.2 using ifort or 4.4.4 using mpiifort.

If I compile using ifort something odd happens with the command line argument handling - every other argument and values is lost. It works fine if you duplicate each argument. That doesn't seem to happen with mpiifort - the command line arguments work just fine then.

The f90getopt.F90 needed the F90 to be added to suffixes and *.o build rules, but now runs fine. If I understand it correctly using F90 indicates that the compiler should automatically apply the preprocessor option.

It currently compiles, and takes arguments, but I've broken something downstream. I get this:

forrtl: severe (59): list-directed I/O syntax error, unit -5, file Internal List-Directed Read

[jedokaplan]

Can you do a backtrace to see exactly where this is crashing? I suspect it is somewhere in parsing the command line arguments.

[davidorme]

Ohhhh. I was just testing that it read the argument correctly and the extents argument was malformatted, so it was passing a bad coordstring to coordsmod.f90. Might be worth adding some sanity checks! I'll see if I can get it to run with more careful inputs.

[jedokaplan]

@davidorme please let me know if we can close this issue.