Error compiling mercury about mercury HOT 8 CLOSED

The issue here is that older gfortran products have missed the -Wsurprising cases with respect to stack vs static memory when a subroutine could be called recursively or in a multithreaded situation: "This makes the procedure unsafe when called recursively, or concurrently from multiple threads" (agree!).

Simple work-around: remove -Wsurprising from the Makefile. However, this is not a real fix but will suffice as bubblegum as long as the code is not significanlty modified. Fragile LARGE Fortran source file: mercury6_2.for!!

I will be opening a PR with a fix to README.md and Makefile.

Best long-term solution (IMHO): Rewrite this project in Julia, Go, or some other efficient code-generating compiler language (No, Python does not qualify as much as I like Python for certain tasks). How about one of you academics finding a brilliant student to take on this huge mind-numbing challenge? (-:

from mercury.

Hi, i'm trying to compile mercury and i'm getting this error with stock mercury.inc. Any ideas?

from mercury.

No problem compiling in Ubuntu 22.04 using gfortran 9.4.0-1ubuntu1~20.04.1.
The error is when compiling in Debian 11 with gfortran version Debian 10.2.1-6. Maybe the code needs to be updated for this compiler.

from mercury.

Hi all,

@texadactyl Thank you for your comment (and your effort in another PR). That's amazing!

I strongly agree with your point that this code has to be rewritten in a modern language (? maybe, Rust). The question is whether it is needed. Our colleagues created an amazing package 'rebound' (https://github.com/hannorein/rebound). Of course, while it is written in python, it is not as fast as this one, but it includes many new integrators, including the updated version of hybrid integration, which works with close encounters (when the denominator tends to 0).

It is not a big deal with rewrite this code into Rust or anything similar. I assume it will take a couple of days. However, the challenge is to support it and, moreover, to be used by others. I'm not sure whether it is true.

from mercury.

@smirik
Conversion effort vs benefit to users - agreed. Its just a pain at times to maintain a program with 1-letter variable names and other quirks! )-:

from mercury.

Sometimes, I enjoy working with fortran77. While it is painful (especially, on f77), it brings low-level coding feeling :)

from mercury.

@smirik
I miss using Assembly Language the most. What other languages can hide data in the back half of an unconditional branch! (:

from mercury.

Maybe, maybe. I forgot Assembler as a bad dream after I had completed the corresponding course. It takes too much time to accomplish a simple task. However, it might depend on my skills that time.

from mercury.