Please refer to the page: SaturneInstallMac as this is no longer maintained

Code_Saturne installation on Mac Os

I'm trying to install Code_Saturne (1.3.1) on my macbook. I have MacOS X 10.4.11 and it hasn't been easy so I'm putting here my experiecens so I won't forget.

First thing to do is get the compilers. The C compiler is within the CD that comes with the Macbook, under dev tools. But a Fortran compiler is necessary. I first installed a version of gfortran which works. But during my many stages of problems I thought it might be related to gfortran and switched to g77. So in theory, gfortran should work but I used g77 for the problems during installation of mpich (see below). I got gfortran and g77 from here.

I started only by trying to get Saturne working so, my first attempt was only to use it serial and therefore minimal installation: bft, fvm, ecs and noyau. No fancy formats no parallel stuff no cool partitioning etc.


I have no real problem at the beginning of the installation of the bft libraries. The only hiccup I encounter was when linking the noyau, it couldn't found all the gzip libraries even though the bft installation found them. So I have to add the flag '-lz' to the BFT libraries in the macros file for the kernel (see below). I do not see why... I will check this one with Yvan.


Here i encounter my first problem. Even though I didn't want any parallel stuff (for the moment) the make of fvm was asking for some MPI_ subroutines in a test file. Again, this is indeed a known problem which is fixed in the soon-to-be-realeased version 1.3.2. It is not directly a problem of fvm (it compiles and run smoothly if you install it) but in the test suite. The proper way of dealing with it is too add a #if defined(HAVE_MPI) at the right position in the right fvm test file. So rather than trying to figure out where was something missing, I decide just to install mpich and do everything in parallel since the macbook has a dual core intel. Obviously that meant that i had to re-install fvm. After I manage to install mpich correctly the fvm was straight forward.


Here there are several possibilities. You can have mpich2, mpich or lam. I had a quick try to mpich2 but got some weird error and since I have always used mpich, I decide to leave mpich2 and go for mpich. I had to download the sources and compile it. Here is where the gfortran started to give me some problems. I wanted to have mpif77, but the mpich compilation didn't seem to create an mpi fortran compiler based on gfortran. Even if I specified the variable FC to the correct path of gfortran and forced --enable-f77 flag.

So I decided to install g77 and try again. It worked and I got my mpif77 executable alongside the mpicc and mpirun.

I would advise not to try mpi at the moment on mac with wink (with the help of the previous fix for fvm).

Update: I did install mpich but it doesn't work properly. The problem is that it gets a 'connection refused error' . The mac has by default rsh disabled, so I tried to compiled mpich with ssh following the advice on the configuration script. I set the variable RSHCOMMAND=ssh and put the flag -rsh=ssh and -rshnol since in the ssh version on Mac the option -l doesn't exist. But still get the connection refused. I'll try to enable rsh just as a test becuase i don't want to have to use rsh.


Here I had three main problems. The first one was with a subroutine called ecs_pre_comet.c . During the make of the ecs, I got an error with the cas of the BIG_ENDIAN variable inside that subroutine. It complaint of error: parse error before numeric constant.

I googled it an appratnly it had something to do with the case of the variables. C being a case sensitive thing of course. So I looked around and found it somewhere else defined in lower case. I don't understand why this only happens on the Macbook compilation, but I thought that since it was very unlikely that I would use a comet mesh here, I decided to just make it lower case inside that subroutine and get on with it. I know is not a nice fix but it did allowed me to continue.

the second problem I had was with a sobroutine called ecs_cmd.c which complainet about the variable ECS_CMD_OPTION_CWD_1 not being defined. I searched for it and couldn't find it anywhere. But I did found ECS_CMD_OPTION_CWD defined as the current working directory. This variable is used on on bft_error subroutine. I have no idea how to fix this except to define it, but again I have no idea what to defined as. So I just decided to drop the trailing _1 and use the variable that was defined. Again not a nice fix, and very probably wrong but it allowed me to continue. This is also a known problem that will be fixed in the next version. By the way, you applied the right patch by dropping the tailing _1.

At this point I thought that I should have installed metis since I had decide to go for the parallel environment. I installed version 4 and not the pre-release 5. But then after recompiling bft anv fvm, the ecs complained about the variables METIS_VER_MAJOR, METIS_VER_MINOR and METIS_VER_SUBMINOR not being defined. I checked and they were supposed to be in the include file metis.h. But there were not on the version 4, only found them on version 5. So i cheated again and included the three variables on the metis.h from version 4. I did try to install the pre-release version but ran into trouble and gave up. Actually you do not need metis for mesh partiniong, it is just strongly adviced (the preprocessor partitions the domain even if you do not have metis installed) ! if you just want to test, you can drop it.

Now the biggest problem I had was this error:

error: 'struct hostent' has no member named 'h_addr'

I googled it an apparently is a bug on the gcc for mac v4. the answer that i saw was to either use a previous version of the compiler or to modify the file /usr/include/netdb.h. I, reluctantly did the later by modifiying it as:

      struct  hostent {
       char    *h_name;    /* official name of host */
       char    **h_aliases;    /* alias list */
       int h_addrtype; /* host address type */
       int h_length;   /* length of address */
       char    **h_addr_list;  /* list of addresses from name server */
   +++ #ifndef _POSIX_C_SOURCE
       #define h_addr  h_addr_list[0]  /* address, for backward compatiblity */
   +++ #endif /* !_POSIX_C_SOURCE */

I don't know that the _POSIX_C_SOURCE variable is but I don't like to leave this file modified manually so at some point I really need to find a fix for this. No idea about this one ! Perhaps a bug in the gcc.. You can try to add -D_POSIX_C_SOURCE in your configure (by setting accordingly the variable CC_ADD when you type ./configure).

Cool, I'll try that and let you know.

Kernel (1.3.1)

With the ecs finally installed, I went for the the kernel. Copied the to and the only change I made was to add the flag '-lz' in the line: BFT_LDFLAGS =-L$(BFT_HOME)/lib -lbft -lz I had to do this before on some other machines because some problems with the gzip libraries. (as usual, the solution came from Google) Could you please attach your file in the TWiki so that I can put officially (especially if your case runs ok).

With that, all went ok and linking was successful. Now I only have to actually try to run a case and see if it works.

-- JuanUribe - 06 Feb 2008

Update: It works!! at least on serial. The only problem in parallel is the conection refused problem with mpich but on single processor works just fine.


Update (25/02/2009):

  • With Leopard, fortran compiler has to be used with -gdwarf-2 instead of -g. Ref.
  • ncs-1.4.0 and ecs-1.4.0 successfully installed on a MBP + Leopard, with bft-1.0.8, fvm-0.12.0 and openmpi-1.3, but SOCKET=1 does not work. No tests in parallel so far. Flavien Billard - 25 Feb 2009

Current Tags:
create new tag
, view all tags
Topic attachments
I Attachment Action Size Date Who Comment
elsemk manage 5.8 K 2008-02-06 - 17:41 JuanUribe macros for Darwin
Topic revision: r9 - 2010-05-11 - 09:02:56 - JuanUribe
Saturne.SaturneOnMac moved from Main.SaturneOnMac on 2010-05-11 - 09:00 by JuanUribe - put it back
Saturne Web
22 Mar 2018
Test Cases

tip Saturne Tip of the Day
Channel flow statistics
Channel flow statistics have been developed and implemented for Code Saturne Version 1.3.1 RichardHoward ... Read on Read more


Code_Saturne collaborative website
@ the University of Manchester
Copyright & by the contributing authors. Unless noted otherwise, all material on this web site is the property of the contributing authors.