OpenMP compilation fails due to return statements in parallel regions

[appy2806]

Environment

• REBOUND Version: [4.4.10] Latest from GitHub (attempting to compile from source with OpenMP support)
• API interface: Python (compiling C extension with OpenMP), pip install rebound seems to work but compiles without openmp support.
• Operating System (including version): Linux (Rocky Linux on HPC cluster)

Describe the bug
Compilation with OpenMP support fails due to invalid return statements within OpenMP parallel regions in src/collision.c. :Line 274, 332. The OpenMP specification prohibits branching out of structured blocks, but the code contains return statements inside #pragma omp parallel for loops that cause GCC to throw compilation errors.

To Reproduce

1. Attempt to compile REBOUND from source with OpenMP support using flags like -fopenmp -O3
2. The compilation fails with errors:

src/collision.c: In function 'reb_collision_search':
src/collision.c:274:41: error: invalid branch to/from OpenMP structured block
  274 |                     if (reb_sigint > 1) return;
      |                                         ^~~~~~
src/collision.c:332:41: error: invalid branch to/from OpenMP structured block
  332 |                     if (reb_sigint > 1) return;
      |                                         ^~~~~~

The problematic code pattern occurs at lines 274 and 332:

#pragma omp parallel for schedule(guided)
for (int i=0;i<N;i++){
#ifndef OPENMP
    if (reb_sigint > 1) return;  // <- This causes the compilation error
#endif // OPENMP
    // ... rest of loop
}

Additional context
The code checks #ifndef OPENMP, but GCC with -fopenmp defines _OPENMP (with underscore), not OPENMP, the return statements are always included when compiling with OpenMP which violate the OpenMP specification within structured blocks.

Installing via pip install rebound works fine (but compiles without OpenMP in my case),

Compiler: GCC 11.2.0 on HPC environment (Flatiron/Rusty)

Potential solutions:

Macro fixes maybe to use _OPENMP instead of OPENMP? Also a flag-based early termination check inplace of return statements?

Name/Affiliation
Arpit Arora, University of Washington.

[hannorein]

The OPENMP precompiler flag is set in the Makefile. See https://github.com/hannorein/rebound/blob/main/examples/openmp/Makefile#L13 and https://github.com/hannorein/rebound/blob/main/src/Makefile.defs#L102

So I'm guessing you might have modified a Makefile?

[appy2806]

I was adding -fopenmp -O3 in the extra_link_args and extra_compile_args.

Otherwise running pip install . wasn't enabling OPENMP support for me. I could try doing a cmake, seems like I need the C++ version available too.

[hannorein]

Oh, I see. You can not use python together with Openmp. (At least I have never tested it)

[appy2806]

Thank you. It seems to have work though. I changed a couple of those returns to continue , I think two in collisions.c and three in gravity.c , added -fopenmp flag.

My use case is to run Nbody (roughly 1M particles) with a tree and leapfrog integration in a time-external potential field.

My first test case was to just compute accelerations using tree for the default opening angle by progressing the 1M particles by a tiny time step. Getting the forces through the tree took about 8 seconds on a single thread and 0.3 secs on 32 threads.

Would you recommend switching to the C++ API ? Are there controls on rebuilding the tree at ever time step versus just updating the tree ?

[hannorein]

It's great that it works! I just never tested it, so I can't vouch for it! I would in general suggest to use the C API (there is no C++ API) for large jobs where speed matters, especially if you run them on a cluster. The python rapper is quite thin and you can do everything quite easily in C.

The tree gets updated every timestep. There is no built-in option to rebuild it from scratch.

[xczics]

I meet the same issue, and it can compile by changing those returns to continue. I'm not sure whether those change will affect the simulations. I'm running a N-body simulation of 10^3-10^4 particles in a cluster, is it a good idea to use OpenMP to speed up?

[hannorein]

Try adding the -DOPENGL flag to the compiler options.