search

smirik / mercury

N-body fortran integrator
GNU General Public License v3.0
60 stars 24 forks source link

Error compiling mercury #27

Closed asterismo closed 1 year ago

asterismo commented 1 year ago

make build gfortran -g -O2 -Wline-truncation -Wsurprising -Werror -o ./close6 ./close6.for ./close6.for:34:40:

34 | character*80 mem(NMESS),cc,c(NMAX) | 1 Error: Array ‘c’ at (1) is larger than limit set by ‘-fmax-stack-var-size=’, moved from stack to static storage. This makes the procedure unsafe when called recursively, or concurrently from multiple threads. Consider using ‘-frecursive’, or increase the ‘-fmax-stack-var-size=’ limit, or change the code to use an ALLOCATABLE array. [-Werror=surprising] f951: all warnings being treated as errors make: *** [Makefile:27: close6] Error 1

asterismo commented 1 year ago

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

asterismo commented 1 year ago

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.

texadactyl commented 1 year ago

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? (-:

smirik commented 1 year ago

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.

texadactyl commented 1 year ago

@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! )-:

smirik commented 1 year ago

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

texadactyl commented 1 year ago

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

smirik commented 1 year ago

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.