Change ids from longlong to int64

I have changed the long long to int64_t for the Ids. It works with/without MPI for the sodshock 3D. Do you wish more tests?

I think it was a bug before to use an unsigned int here as the variable is a signed int.

Not sure. It depends also on what type is actually used in the ICs.

It is the same for the output. It should be fine as HDF5 converts the data type, but I was wondering if you were doing it in order to remove the negative IDs from the gparts.

gparts that are actually written (as they are DM) should have a positive ID.

@jborrow can you try this on apple and on arm?

mentioned in merge request !813 (merged)

Errors on ARM (although this is probs not ARM related):

In file included from fof.c:39:
In file included from ./black_holes.h:31:
././black_holes/EAGLE/black_holes_iact.h:200:63: error: format specifies type
      'long long' but the argument has type 'int64_t' (aka 'long')
      [-Werror,-Wformat]
        message("BH %lld wants to swallow gas particle %lld", bi->id, pj->id);
                    ~~~~                                      ^~~~~~
                    %ld
./error.h:124:28: note: expanded from macro 'message'
           __FUNCTION__, ##__VA_ARGS__);                                      \
                           ^~~~~~~~~~~
In file included from fof.c:39:
In file included from ./black_holes.h:31:
././black_holes/EAGLE/black_holes_iact.h:200:71: error: format specifies type
      'long long' but the argument has type 'int64_t' (aka 'long')
      [-Werror,-Wformat]
        message("BH %lld wants to swallow gas particle %lld", bi->id, pj->id);
                                                       ~~~~           ^~~~~~
                                                       %ld
./error.h:124:28: note: expanded from macro 'message'
           __FUNCTION__, ##__VA_ARGS__);                                      \
                           ^~~~~~~~~~~
In file included from fof.c:39:
In file included from ./black_holes.h:31:
././black_holes/EAGLE/black_holes_iact.h:209:13: error: format specifies type
      'long long' but the argument has type 'int64_t' (aka 'long')
      [-Werror,-Wformat]
            bi->id, pj->id, pj->black_holes_data.swallow_id);
            ^~~~~~
./error.h:124:28: note: expanded from macro 'message'
           __FUNCTION__, ##__VA_ARGS__);                                      \
                           ^~~~~~~~~~~
In file included from fof.c:39:
In file included from ./black_holes.h:31:
././black_holes/EAGLE/black_holes_iact.h:209:21: error: format specifies type
      'long long' but the argument has type 'int64_t' (aka 'long')
      [-Werror,-Wformat]
            bi->id, pj->id, pj->black_holes_data.swallow_id);
                    ^~~~~~
./error.h:124:28: note: expanded from macro 'message'
           __FUNCTION__, ##__VA_ARGS__);                                      \
                           ^~~~~~~~~~~
In file included from fof.c:39:
In file included from ./black_holes.h:31:
././black_holes/EAGLE/black_holes_iact.h:209:29: error: format specifies type
      'long long' but the argument has type 'int64_t' (aka 'long')
      [-Werror,-Wformat]
            bi->id, pj->id, pj->black_holes_data.swallow_id);
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./error.h:124:28: note: expanded from macro 'message'
           __FUNCTION__, ##__VA_ARGS__);                                      \
                           ^~~~~~~~~~~
In file included from fof.c:39:
In file included from ./black_holes.h:31:
././black_holes/EAGLE/black_holes_iact.h:310:62: error: format specifies type
      'long long' but the argument has type 'int64_t' (aka 'long')
      [-Werror,-Wformat]
        message("BH %lld wants to swallow BH particle %lld", bi->id, bj->id);
                    ~~~~                                     ^~~~~~
                    %ld
./error.h:124:28: note: expanded from macro 'message'
           __FUNCTION__, ##__VA_ARGS__);                                      \
                           ^~~~~~~~~~~
In file included from fof.c:39:
In file included from ./black_holes.h:31:
././black_holes/EAGLE/black_holes_iact.h:310:70: error: format specifies type
      'long long' but the argument has type 'int64_t' (aka 'long')
      [-Werror,-Wformat]
        message("BH %lld wants to swallow BH particle %lld", bi->id, bj->id);
                                                      ~~~~           ^~~~~~
                                                      %ld
./error.h:124:28: note: expanded from macro 'message'
           __FUNCTION__, ##__VA_ARGS__);                                      \
                           ^~~~~~~~~~~
In file included from fof.c:39:
In file included from ./black_holes.h:31:
././black_holes/EAGLE/black_holes_iact.h:320:13: error: format specifies type
      'long long' but the argument has type 'int64_t' (aka 'long')
      [-Werror,-Wformat]
            bi->id, bj->id, bj->merger_data.swallow_id);
            ^~~~~~
./error.h:124:28: note: expanded from macro 'message'
           __FUNCTION__, ##__VA_ARGS__);                                      \
                           ^~~~~~~~~~~

Fixed!

Another ARM error, unrelated to this MR?:

Note this only occurs with --enable-parallel-hdf5

libtool: link: mpicc -I../src -I../argparse -I/mnt/beegfs-ssd/apps/fftw/openmpi-4.0.1/arm-19.3/3.3.8/include -DWITH_MPI "-DENGINE_POLICY=engine_policy_keep | engine_policy_setaffinity" -I/mnt/beegfs-ssd/apps/hdf5/openmpi-4.0.1/gcc-8.2/1.10.5/include/ -O3 -fomit-frame-pointer -fstrict-aliasing -ffast-math -funroll-loops -mcpu=native -pthread -Wall -Wextra -Wno-unused-parameter -Wshadow -Werror -Wstrict-prototypes -o swift_mpi swift_mpi-main.o  ../src/.libs/libswiftsim_mpi.a ../argparse/.libs/libargparse.a -lhdf5 -L/mnt/beegfs-ssd/apps/fftw/openmpi-4.0.1/arm-19.3/3.3.8/lib /mnt/beegfs-ssd/apps/fftw/openmpi-4.0.1/arm-19.3/3.3.8/lib/libfftw3.so -lnuma -lm -pthread -Wl,-rpath -Wl,/mnt/beegfs-ssd/apps/fftw/openmpi-4.0.1/arm-19.3/3.3.8/lib -Wl,-rpath -Wl,/mnt/beegfs-ssd/apps/fftw/openmpi-4.0.1/arm-19.3/3.3.8/lib
/opt/arm/gcc-8.2.0_Generic-AArch64_SUSE-12_aarch64-linux/lib/gcc/aarch64-linux-gnu/8.2.0/../../../../aarch64-linux-gnu/bin/ld: ../src/.libs/libswiftsim_mpi.a(mpi-parallel_io.o): in function `readArray':
parallel_io.c:(.text+0x11e8): undefined reference to `H5Pset_dxpl_mpio'
/opt/arm/gcc-8.2.0_Generic-AArch64_SUSE-12_aarch64-linux/lib/gcc/aarch64-linux-gnu/8.2.0/../../../../aarch64-linux-gnu/bin/ld: ../src/.libs/libswiftsim_mpi.a(mpi-parallel_io.o): in function `prepareArray':
parallel_io.c:(.text+0x17d8): undefined reference to `H5Pset_dxpl_mpio'
/opt/arm/gcc-8.2.0_Generic-AArch64_SUSE-12_aarch64-linux/lib/gcc/aarch64-linux-gnu/8.2.0/../../../../aarch64-linux-gnu/bin/ld: ../src/.libs/libswiftsim_mpi.a(mpi-parallel_io.o): in function `writeArray_chunk':
parallel_io.c:(.text+0x1dcc): undefined reference to `H5Pset_dxpl_mpio'
/opt/arm/gcc-8.2.0_Generic-AArch64_SUSE-12_aarch64-linux/lib/gcc/aarch64-linux-gnu/8.2.0/../../../../aarch64-linux-gnu/bin/ld: ../src/.libs/libswiftsim_mpi.a(mpi-parallel_io.o): in function `read_ic_parallel':
parallel_io.c:(.text+0x236c): undefined reference to `H5Pset_fapl_mpio'
/opt/arm/gcc-8.2.0_Generic-AArch64_SUSE-12_aarch64-linux/lib/gcc/aarch64-linux-gnu/8.2.0/../../../../aarch64-linux-gnu/bin/ld: ../src/.libs/libswiftsim_mpi.a(mpi-parallel_io.o): in function `write_output_parallel':
parallel_io.c:(.text+0x6b84): undefined reference to `H5Pset_fapl_mpio'
/opt/arm/gcc-8.2.0_Generic-AArch64_SUSE-12_aarch64-linux/lib/gcc/aarch64-linux-gnu/8.2.0/../../../../aarch64-linux-gnu/bin/ld: parallel_io.c:(.text+0x6bf0): undefined reference to `H5Pset_all_coll_metadata_ops'
/opt/arm/gcc-8.2.0_Generic-AArch64_SUSE-12_aarch64-linux/lib/gcc/aarch64-linux-gnu/8.2.0/../../../../aarch64-linux-gnu/bin/ld: parallel_io.c:(.text+0x9138): undefined reference to `H5Pset_all_coll_metadata_ops'
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:748: recipe for target 'swift_mpi' failed
make[2]: *** [swift_mpi] Error 1
make[2]: Leaving directory '/mnt/beegfs-ssd/home/dc-borr/swiftsim-int64/examples'
Makefile:507: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/mnt/beegfs-ssd/home/dc-borr/swiftsim-int64'
Makefile:438: recipe for target 'all' failed
make: *** [all] Error 2

First one is not due to ARM. What are your configuration options?

Just --with-subgrid=EAGLE should produce this error.

First one is due to %ld not being the correct thing in a printf for an int64_t.

Apart from the issues with the string printing, this seems to compile and run on both platforms (__APPLE__ and ARM). It compiles and runs without complaint and produces valid IDs in the output.

added 1 commit

• 401e1347 - fix compilation errors

Compare with previous version

It should be fine now, but I am not able to reproduce the second bug. Is Jenkins dead?

The second bug is a problem on the ARM platform unrelated to this issue.

Jenkins is down since the whole Durham system is down.

Thanks for the fixes that now compiles.

Are we waiting on something?

@jborrow can you try the updated version again?

Also, has this been tested on ICs that have large IDs like the EAGLE-25 from ICs?

I will try the EAGLE-25 tomorrow.

Sure, I can check this again. I haven't tried it on any particularly testing cases, though.

Any updates?

I am able to run for 230 steps of EAGLE_25, but unfortunately the first snapshot is done at z=18, therefore it takes a lot of time to reach it (specially as I was running on a single node). I am running now with more nodes and a first snapshot at far higher redshift.

The initial snapshot (0000) is dumped without any problem, but I am not able to check if the IDs are correct due to the creation of new particles between the IC and the snapshot 0.