smirik/mercury

N-body fortran integrator

mercury's Issues

Enhancement request: Update README.md

This is probably low priority for 4xxi. When time permits, I would suggest making the following amendments:

• Move the original "John E. Chambers" documentation into a separate file to be preserved for history. File mercury6.man seems to be an update to the Chambers documents. Do they need to be merged somehow?
• Move the revision history to a separate file. Implement version numbers.
• Document the actual instructions for making the 3 executable programs (make build).
• Document all of the make parameters.

Would be nice to have too, as much as we know:

• Document the individual parameters of the sample parameter files (*.in.sample).
• Document the individual variables of the Fortran include files (*.inc). Note that this is a mix of constants and additional parameters.

Different results if Intel or AMD processor possible?

Is there any possibility to get different results running the very same integration with different CPU architectures? say, Intel and AMD?

Updated big.in

Hi, i notice the big.in has an epoch of 2457724.5D0 and th ifile is 3 years old. I wonder if this is extracted by the DE431 positions. JPL/Horizons has planet positions for DE431 and the epoch in that paper is JD (TDB) 2440400.5, are big.in positions bettert than these?

A few issues fixed; donationware

I was referred to 4xxi/mercury by Cal Tech Professor Mike Brown. I am one of his current Coursera students [I am a bit old for a student but Fortran IV/77 was like walking down "Memory Lane"].

I did not change any of the Science algorithms. I left virtually all of the source code as-is. But, I did get rid of all of the compiler warnings and fixed some obscure issues in character handling. In addition, I created suggested sub-folders for organization (maybe you will like it). It now compiles with a Makefile. All of the changes are documented in file 20180507_texadactyl.txt at the same level as README.md.

Attached is a ZIP file of mercury-master.
mercury-master.zip

Best wishes ..... Richard

Obliquity calculation and valid spin angular momentums for the bodies

Hello,

I try to calculate the obliquity of some planets. If I understand the code, I have to enter
valid spin angular momentus in big.in.
Does anybody have a clue where I can get these values?

mfo_user user define force Issue

Hi,

I have a problem when I write user define force in mfo_user function. I have attached the zip file below. This problem still exists if change the code to Fortran 90.

In mercury6_2_default_newJ2_constK2.for, I define the force in mfo_user functions.
When J2planet = xco/((time/day) + 1.d6) (line:268), all looks good.

However, if I have
rtime = (time/day) + 1.d6
J2planet = xco/rtime

It will cause planets being ejected at the beginning, and *.aei files have only one timestep data.
info.out will have:
K342e ejected at 8.22000 days
K342b ejected at 8.22000 days
K342c ejected at 8.22000 days
K342d ejected at 16.44000 days

This issue really confuses me because the assignments look all right. And there are many similar circumstances will cause ejection at the beginning (I only show one example here to clarify...), which looks pretty unreasonable.

Do you have any idea about this situation?
Thank you so much for the help in advance!

Software License

Hi,
I am interested in using these tools, but they don't seem to have any software license.

Would you consider adding a license such as the MIT open source license or similar?
https://opensource.org/licenses/MIT

Without a license, this technically shouldn't be used without explicit permission from the authors.

Thanks

Total number of bodies exceeds NMAX (ONLY in close6 execution)

Hi everyone,

I have realized during test of hundreds small particles that when the number of bodies in small.in is greater than 200, close6 execution crashes giving the following error:
ERROR: The total number of bodies exceeds NMAX.
I have made the pertinent changes in mercury.inc and swift.inc. The mercury6 and element6 executions work fine with any number of small bodies (always according to the specified limits on the .inc files) but close6 execution crashes at the 200th small body. For example, if the Moon is where all small bodies are having a close encounter (they launch from the Moon's surface) the list of the close encounter (dmin, orbital elements, etc.) is completed until 200th body.

I cannot figure out why this is happening. Any help will be much welcomed! thanks

PS: Current parameters defined:
in swift.inc
NPLMAX = 2002
NTPMAX = 2000

in mercury.inc
parameter (NMAX = 4003)
parameter (CMAX = 8000)
parameter (NMESS = 100)
parameter (HUGE = 9.9d29)
parameter (NFILES = 50)

See attachments for big.in, small.in, param.in
i_VgitTEST.tar.gz

gfortran with -O2 compiles but does not run in older processors

Hi, i have a Dell Precision 530MT old workstation with a dual Intel Xeon (Pentium 4s) processors running Debian 7 32bits. I cloned the repo and did "make build" and it builds it with no error, but then ./mercury get stucked in integrating particles to the same epoch. I figured out that the -O2 in the Makefile was the issue, if i remove it, it compiles and executes ok and complete the integration. Any idea why is this?

Data from JPL vs original data

Hi, mercury,

I was using mercury with different step sizes and different integrators with original data from mercury and new data from mercury(JPL:16-12). For original data, the Pluto is stable, however, with JPL's data in mercury, the Pluto is not stable (the semi-major axis is not stable) in 1M years. Do you know which data is more reliable?

Best,
Renyi

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

I modified NMAX to 20000 objects, and recompiled. Executed the integrator and i got a segfault.

I pasted in Los Molinos Observatory pastebin.

https://pastebin.oalm.gub.uy/view/94773e01

At the bottom of the pastebin is the error.

README.md instructions for "How to use" are incorrect (suggestion enclosed)

And, it recently caused an unnecessary bug report (#21).

Set up for running a model:

1. Initialize the *.in files from the samples: make gen-in
2. Edit the *.inc and *.in files as needed for the model at hand (your application).
3. Remove any existing old generated files (E.g. results of previous execution): make rm-gen
4. Un-build the Fortran programs: make unbuild
5. Build the Fortran programs: make build
6. Make sure that there are no compilation errors in the previous step.

Now, you are ready to run your model. Three steps:

1. mercury6
2. element6
3. close6

Simplistic, perhaps. But, a rough outline at least.
Feedback?

add topics

I suggest adding topics such as astronomy, integrator bulirsch–stoer in the About section at https://github.com/smirik/mercury.

Integration issue

I am a student who is trying to run the integration for 100 million years. It ran fine for around 5.8 Million years but suddenly it started showing the years in -ve and then it became constant (attached screenshot). I have 21 big bodies and no small bodies. Can anyone help me understand what is happening and how to continue with the integration?

Accuracy in simple test

I´ve downloaded the sources and compiled them.
I left all *.in files untouched except that I changed calculation interval in param.in and set it to 100 years.
After the calculations were completed I run element6 to get output files in a readable form.
I see that the perihelion precession of Mercury is 980 arcseconds per century that is almost twice larger than the observational value.
Is it OK?

Suggestion for a change-tracker wiki

Its not necessary to create a full-blown wiki for this project. But, I thought that it might be useful to track changes in human-readable form. Not sure how you two feel about that.

I just wrote up an idea as an after-thought today:
https://github.com/texadactyl/mercury/wiki/Change-History-for-Project-Mercury

IEEE invalid operation when checking for central body collision

Hi all,

I sometimes stumbled across the following warning message when running Mercury:

Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG

With not much more to go on, I added the gfortran compiler flag -ffpe-trap=invalid (and removed -O2 as otherwise the debugger didn't shoe the correct line) to find the problem: calling acos() for an undefined value. Here is the part (line 963 in mercury6_2.for):

u0 = sign (acos((1.d0 - r0/a )/e), rv0)

I then added some debug output to check the values of r0, a, e and rv0 right before the error:

parameter	value
r0	8699.8554879043295
a	4349.9294907593367
e	0.99999919683544536
inside acos	-1.0000000000218023
rv0	-8.0957151629424393E-006

I run large suites of simulations, keeping big.in the same but having randomized particles in small.in, so every run is slightly different, and it doesn't happen in most runs. I attached the initial conditions for a sample run where the bug does occur.

• System: Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-76-generic x86_64)
• gfortran: GNU Fortran (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0 using the provided Makefile
• Mercury: most up-to-date version of this repository, except for three parameters I changed in mercury.inc before compiling (CMAX = 1000 and NFILES = 200)

A possible solution is referenced in #18, but it's probably not the best way as it masks possible other bugs as was pointed out.

Cheers

Error compiling mercury

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