[Mesa-users] MESA with intel compilers
chang65 at uwm.edu
Tue Apr 30 11:50:04 EDT 2019
It may be more trouble than it is worth. But I have been able to
compile this on exactly one supercomputer (stampede2) out of the few I
have access to, which include: niagara (on scinet), and rusty at
flatiron. I haven't tried pleiades, but the setup is similar to rusty,
so I doubt it will make a difference.
I am further constrained by the fact that I want to use both ifort and
icc. That being said, I have found the following incantations and
prayers to work for the icc gods at least on stampede2.
First replace in utils/private/utils_c_system.c
static const int LEN_TEMP=strlen(TEMPLATE);
#define LEN_TEMP strlen(TEMPLATE)
The first line produces a warning in gcc, but icc barfs on an error.
Second in crlibm/crlibm/Makefile.in/am
replace the compiler flag "-mp" with "-mieee-fp -O1"
You will need to do a rebuild to ensure that the flags get incorporated
into the build.
On stampede, this compiles to the point of mesa star with "-O2" in the
where it barfs on the unit test evolution. With "-O1" it goes all the
I don't know if this help anyone out there. Mileage may vary. I seem to
be able to get it to work on stampede2, but not on niagara, which is a
On 4/29/19 3:27 AM, Warrick Ball wrote:
> Hi Phil,
> I've attached a `utils/makefile_header` that I just used to build
> r11554. I'm using ifort 18.0.1 and I had to set the optimisation flag
> to -O1 (rather than -O2, as distributed). My University cluster
> provides packages and libraries with the Environment Modules system,
> so I get a convenient environment variable for the locations of the
> HDF5 libraries.
> I just tried building with ifort 17.0.1, 16.0.1 and 15.0.2 instead
> with the same `makefile_header` and `crlibm` built fine. Could you
> attach your `makefile_header` and `build.log` after a top-level
> `./touch`? In all three cases GCC is version 5.4.0.
> Regarding the optimisation flag, most of MESA builds OK with -O2 but
> the `star` module fails its unit test. The small test evolutionary
> run just never seems to converge on a model and I've never really had
> the time to work out why. I accidentally did a mixed build of -O2 in
> the modules and -O1 in `star` last week. That passed on *nearly* the
> whole test suite.* The long and short is that if you're only using
> some of the modules, you can possibly try your like with -O2 but know
> that the modules are currently only integration-tested with -O1.
> I did spend some time building different files in `star` with
> different optimisation flags and seeing when `star`'s unit test passed
> and it looks like `star/private/star_bcyclic.f90` might be where the
> -O2 vs -O1 problem comes in. But even if that were fixed it also
> looks like something in another module causes the few test case
> * For interested readers, the test cases that failed in my
> accidentally-mixed build were
> Warrick Ball
> Postdoc, School of Physics and Astronomy
> University of Birmingham, Edgbaston, Birmingham B15 2TT
> W.H.Ball at bham.ac.uk
> +44 (0)121 414 4552
> On Sat, 27 Apr 2019, Philip Chang wrote:
>> Hello All,
>> I heard a rumor recently that someone in the mesa community has gotten
>> recent versions of mesa to compile with the intel compiler. Up to now I
>> have been compiling mesa with gcc (no supplied by the mesasdk) to
>> crosslink it with my moving-mesh code. This isn't perfect as mesa does
>> not build all the way with compilers not in the sdk, but does build
>> mesaeos which is all I need.
>> I have gotten some limited progress with the intel compiler -- before it
>> was failing on crlibm. Now it get by, but fails on a bad test
>> comparison in crlibm. If any can tell me their secret sauce on compiling
>> with the intel compilers, I would be really grateful.
>> mesa-users at lists.mesastar.org
More information about the Mesa-users