[Mesa-users] MESA with intel compilers

[Rob Farmer]

Hi,
>The first line produces a warning in gcc, but icc barfs on an error.

Ah that explains why it fails for you, we normally suggest just using gcc
with crlibm (even if you use ifort for the fortran compiler). As you've
seen with changing O2 to O1, intel can do odd things to numerical results
if your not careful.

Rob


On Tue, 30 Apr 2019 at 17:50, Philip Chang <chang65 at uwm.edu> wrote:

> Hi Warrick,
>
> 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);
>
> with
>
> #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
> way through.
>
> 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
> similar environment.
>
> Cheers,
>
> Phil
>
>
> 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
> > failures.*
> >
> > Cheers,
> > Warrick
> >
> > * For interested readers, the test cases that failed in my
> > accidentally-mixed build were
> >
> > 25M_pre_ms_to_core_collapse
> > black_hole
> > example_make_pre_ccsn
> > split_burn_20M_si_burn_qp
> > split_burn_big_net_30M
> > split_burn_big_net_30M_logT_9.8
> >
> >
> >
> >
> >
> > ------------
> > 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.
> >>
> >> Cheers,
> >>
> >> Phil
> >>
> >> _______________________________________________
> >> mesa-users at lists.mesastar.org
> >> https://lists.mesastar.org/mailman/listinfo/mesa-users
> _______________________________________________
> mesa-users at lists.mesastar.org
> https://lists.mesastar.org/mailman/listinfo/mesa-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20190501/4bb4910e/attachment.html>