Falcon stdc++17

[jcldc]

In this branch, the Dehnen code (falcON) is now compatible with the C++17 standard. When compiling, there are practically no more warnings, both with g++ (Linux) and with clang++ on Mac Intel/ARM.

In the make.gcc and make.clang configurations files, I have forced the C++11 standard because some compilers are not yet C++17 compatible.

[teuben]

The VERSION is still 3.6, we should change that.

The "make check" and "make bench5" didn't' show any issues, but I found a small difference in the final result of another test done, two ways:

mkplummer /tmp/p1000 1000 seed=1000
gyrfalcON /tmp/p1000 . eps=0.05 tstop=10 kmax=6

old: 10.000000000 -0.2313544935 0.2377831 -0.4691376 -0.4676625 1.0169 0.01568 3.2e-08   4 10  0.00  0.00  0.00   0:00:00.63
new: 10.000000000 -0.2313409586 0.2377885 -0.4691295 -0.4676696 1.0169 0.01568 1.6e-08   4 10  0.00  0.00  0.00   0:00:00.63

mkplum /tmp/p2000 2000 seed=2000
gyrfalcON /tmp/p2000 . eps=0.05 tstop=10 kmax=6

old: 10.000000000 -0.1406786710 0.1399422 -0.2806209 -0.2802907 0.9986 0.01564 0.00508   8 13  0.00  0.00  0.00   0:00:01.21
new: 10.000000000 -0.1406786360 0.1399423 -0.2806210 -0.2802907 0.9986 0.01564 0.00508   8 13  0.00  0.00  0.00   0:00:01.21

I ran this on Ubuntu 22.04 with g++ 11.4. Will also test with a g++ 14

[jcldc]

For the diferrences, they are very small. It can be the result of the compilation with "-std=c++11", plus some modifications. It does not seem to be critical.
For the Version number, well, it could be 3.7.

[jcldc]

Btw, to be compatible with c++17, I had to remove some "register" keyword, which could be why there are some tiny differences in the results.

[teuben]

version really is a MUST!

Although the differences are small, the regression test is being run with "make check" does not show any differences. Quite puzzling. Regression is on a 1024 plummer, to tstop=2, and the Etot shows a difference in the 9th decimal instead of the 8th.

[jcldc]

Are you considering merging this branch at some point?

[teuben]

Yes, I think we only need a new version ID....but should it be just gyrfalcon? Btw, I'm snorkeling in Fiji as we speak, but flying back this evening

…

On Thu, Sep 18, 2025, 03:26 Jean-Charles Lambert ***@***.***> wrote: *jcldc* left a comment (teuben/nemo#200) <#200 (comment)> Are you considering merging this branch at some point? — Reply to this email directly, view it on GitHub <#200 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZ4MGOFI67MV77AEQQOG5D3TF4QVAVCNFSM6AAAAACE262AYCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMBTGUZDOOJTGI> . You are receiving this because you commented.Message ID: ***@***.***>

[jcldc]

What do you mean by new version ID ?

(Lucky guy in Fidji)

[jcldc]

Ok, I see, it's too early to merge in master.
No pb.

[teuben]

in falcON/src/public/exe/gyrfalcON.cc we should then edit the

#define falcON_VERSION   "3.6"
#define falcON_VERSION_D "19-jun-2012 Walter Dehnen                          "

but the problem is now that every executable would need such a patch :-( There is no VERSION type tag for the library. On the other hand, gyrfalcON is the main engine, and I would probably like on a user level that one can see this is the new version

gyrfalcON --version
gyrfalcON  3.6 (19-jun-2012 Walter Dehnen                          )

so I would suggest we just change the 3.6 to 3.7 (and the date). I guess would keep Walter as the main author.

[jcldc]

so I would suggest we just change the 3.6 to 3.7 (and the date). I guess would keep Walter as the main author.

Yes sure !