G95 on Mac OS X

[cvl]

Has anyone out there successfully compiled ROMS on Mac OS X using either of the free (beer) g95 versions? I took a very abortive stab at it and got some errors mentioning the include statements.

The two g95 projects I'm referring to are:

http://hpc.sourceforge.net/

http://g95.sf.net/

I'm aware of successful g95 compiles in Linux, but my brief investigation that suggests that the transition is not trivial. I'll give it a try, but wouldn't mind hearing from anyone who has done it!

[m.hadfield]

Has anyone out there successfully compiled ROMS on Mac OS X using either of the free (beer) g95 versions?

Well, no. I have compiled and run ROMS (many times) with g95 on Linux and Windows/Cygwin.

I took a very abortive stab at it and got some errors mentioning the include statements.

This suggests a preprocessor problem, not a compiler problem. In the ROMS build system the compiler never sees the include statements.

The two g95 projects I'm referring to are: http://hpc.sourceforge.net/, http://g95.sf.net/

The second of these is G95. The first refers to gcc 4.0, which includes a F95 compiler. The latter is called "Gnu Fortran 95" or "gfortran" and it has its own home page at

http://gcc.gnu.org/fortran/

It is definitely not the same as G95. I've tried to compile ROMS with gfortran several times over the last 6 months or so and never succeeded.

I'm aware of successful g95 compiles in Linux, but my brief investigation that suggests that the transition is not trivial. I'll give it a try, but wouldn't mind hearing from anyone who has done it!

You may not find this very helpful, but I should think the transition *would* be nearly trivial. ROMS is largely platform-independent. If you have G95, Gnu cpp and Gnu make, you should be able to do it. The hardest part is likely to be building netCDF.

If you're still having problems, please describe them in more detail here and we'll see what we can do to help. If you succeed, please report that too.

[cvl]

Briefly, using g95 from http://g95.sf.net with Netcdf 3.5.1-16 downloaded through Fink, I've managed to build and run the upwelling case in roms-2.2 on my powerbook.

I'll try to clean up the process a bit more, but loosely speaking, the minor pitfalls were:

Code: Select all

cp Compiler/Linux-g95.mk Compiler/Darwin-g95.mk
export NETCDF_INCDIR=/sw/include
export NETCDF_LIBDIR=/sw/lib
export FORT=g95
make

Then I had to edit mod_strings.f90 and insert single quotes around MY_FORT, etc.

Code: Select all

make
ranlib libMODS.a 
ranlib libNLM.a 
ranlib libUTIL.a 
make

This got me an executable oceanS, though I haven't checked the quality of the results. The two extant annoyances are:

1. The fact that the substitution of MY_FORT, MY_OS, etc at the end of Modules/mod_strings.F is currently not clean.
2. The need to ranlib all the modules before the final compilation.

This is mostly a recreational exercise; I'll try a benchmark someday, though a 1.33GHz G4 Powerbook is not my best platform choice. I'd still appreciate any input on the extant issues, as well as suggestions for optimization flags that might be worthwhile. I think I'll skip any OpenMP or MPI attempts for now.

Thanks!
CVL

[m.hadfield]

Thanks for that. Re the 2 issues:

The fact that the substitution of MY_FORT, MY_OS, etc at the end of Modules/mod_strings.F is currently not clean.

I can claim the credit/blame for that piece of code. MY_FORT, MY_OS, etc are preprocessor macros, defined via the command line with code like the following in the master makefile:

Code: Select all

mod_strings.f90: CPPFLAGS += -DMY_OS="'$(OS)'"

This is supposed to insert single quotes into MY_FORT, MY_OS as part of the macros so no quotes should be needed in mod_strings.F. OK, it looks flakey, but the tricky stuff is in the makefile, which we know will be processed by Gnu make. It works on all the platforms I have tried (Linux-*, CYGWIN-*, OSF1-f90, UNICOS-mk-f90).

I wonder why it doesn't work for you? It must be a preprocessor issue, I think. What preprocessor are you using? Does it have a switch that might alter its behaviour in this regard? Like "-traditional"?

The need to ranlib all the modules before the final compilation.

Hmmm. The lib*.a files are created by commands in their respective Module.mk files, thus:

Code: Select all

$(local_lib): $(local_objs)
	$(AR) $(ARFLAGS) $@ $^

I guess a "ranlib" command could be added here. The platform-specific make files already define a RANLIB variable, presumably for this purpose, but it is never used anywhere. So the above could be changed to...

Code: Select all

$(local_lib): $(local_objs)
	$(AR) $(ARFLAGS) $@ $^
	$(RANLIB) $@

I wonder if there are any platforms on which this would fail. It would be a pity to have to add any platform-specific conditionals here.

[kate]

I also had to add the ranlib lines for the Mac, for the IBM compiler. Systems that don't have ranlib can set RANLIB=touch in the machine file.

[babsona]

I made a make file Darwin-xlf.mk which I'm happy to share with anyone also using this setup. Thanks for pointing out the mac issues above in this thread. I also found it necessary to make a number of changes to makefile, for some reason. In particular
uname -m was being flaky, so I had to specify that manually
the "modules" and "includes" lists were having trouble with the Adjoint, Representer, Tangent and SeaIce options, so I deleted them since they're not being used in this version

In my efforts to upgrade to 2.2, I can get an example to compile and run, but I'm running into a problem with getting the example to run in MPI, which brings me to my question:
I get errors like the following
1586-206 (S) Unresolved reference to symbol "_mpi_init".
1586-206 (S) Unresolved reference to symbol "_mpi_comm_rank".
1586-206 (S) Unresolved reference to symbol "_mpi_finalize".
Why would there be an extra underscore added to all the CALL mpi_ commands (these are called in ocean.h and distribute.F)? Any suggestions on how to fix this?
Thanks, Amanda

[babsona]

the above mpi problem can be solved by adding a line
LIBS += $(MPI_LIB)
to the .mk file. I'm slowly figuring out how these things work.

[jiangtao]

[quote="babsona"]
In my efforts to upgrade to 2.2, I can get an example to compile and run, but I'm running into a problem with getting the example to run in MPI, which brings me to my question:
I get errors like the following
1586-206 (S) Unresolved reference to symbol "_mpi_init".
1586-206 (S) Unresolved reference to symbol "_mpi_comm_rank".
1586-206 (S) Unresolved reference to symbol "_mpi_finalize".
Why would there be an extra underscore added to all the CALL mpi_ commands (these are called in ocean.h and distribute.F)? Any suggestions on how to fix this?

I'm new on using roms and am trying to run roms-2.2 on SGI with IRIX64. And I got the following errors:
Unresolved text symbol "mp_numthreads_"-- 1st referenced by libUTIL.a(mp_routines.o)
Unresolved text symbol "mp_my_threadnum_"

Is this problem similar to the above? How could I fix it? Thanks for your input.

By the way, I tried the model on another Linux machine using ifort. At least it compiles and runs with no problem.