Where to download ifort 15.0.7?

[JoseLozano]

Hello dear community,

I'm trying to compile a modified version of a cosmological code called CAMB from Anthony Lewis. The issue is that I need the Intel Fortran compiler version 15.0.7. It is old but very important to compile this code. Of course, this cosmological code can be compiled with the latest version of ifort but the modified version cannot. 

Anyone knows how to download this ifort 15.0.8? I've been struggling for an entire month to get this specific version. I hope anyone can show me or, possibly, give a link to directly download it.

Thank you so much for reading this and I hope you can give me an useful information

[Steve_Lionel]

The segfault is probably the least of your concerns, given the NaNs. Do you know how to use the debugger? I would suggest first doing a simpler build, without optimizations or OpenMP and with debug information and traceback.  -qopenmp-stubs will run the program in serial mode. I'm not going to try to debug your application for you.

Most likely, this code has other bugs that are being revealed by newer optimizations. Perhaps there's data corruption happening.

[mecej4 · Accepted solution]

I built just the CAMB executable on Windows, not a shared library, so I did not touch or use camb_python.f90. I did not enable OpenMP, attempt to generate PIC, or use their makefile.

Note that your build completed the first part (building the camb executable) with just a warning. I suggest that you run the newly built camb on some test problems and examine the output results before attempting to build a shared library and using that library from Python.

Line 405 of camb_python.f90 has "use Transfer", and that is a line that probably needs to be replaced by "use Transfer, xcept => c, ycept => EV", just as I suggested above for file cmbmain.f90.

[JoseLozano]

Funciona!!! It works!!! Funktioniert!!!

Thank you Mecej4 for your godly help. It compiled perfectly and the CAMB exe file run without problems!

[mecej4]

It is sobering to note that in the year 2012,  "Antony" (presumably, Antony Lewis, the author of the original CAMB software), had run into the very same issue (the additional dummy argument EV of DVERK being declared REAL and corresponding to an argument of type(EvolutionVars) EV in subroutine DERIVS, etc.).

In his response to that post, Steve had remarked, "The code is NOT correct - in Recombination_init, RECOMB is TYPE(RecombinationParams), but the corresponding dummy argument EV in DVERK is REAL".

[JohnNichols]

It is just as sobering to think that people actually trust programmers to get it correct, I wonder how much incorrectness there is in all the code that life depends upon.  

We used to do a lot a stuff  with experimentation, now we use computer models.