Leaner code & active max h collection

A series of updates:

• Free foreign particles and the mesh before i/o operations.
• Free foreign particles before exchanging the proxy cells.
• Hide the unnecessary fields into anonymous unions inside the cell sub-structures to save memory.
• Collect the max active h of each cell.

The first three updates are currently in use in the Sibelius-dark run. The last change is not used yet for performance improvement but will be used in a future push that focuses solely on using the quantity to speed-up loops. At the risk of confusing things, I added it here already as I was making substantial changes to the cell structure organisation.

added cleanup code health enhancement memory usage labels

My main concern really is the use of the anonymous union in the cell structure. It's working but I can't convince myself it's a good solution that won't bite us back down the line.

Do we need to bother with these when the fof or raptor are not about to run?

I was pondering this as well. FOF does only allocate a small amount of extra memory. The main problem really is the following snapshot writing call. If we are not writing all the particles (e.g. we have DM and background DM types or we have just 1 inhibited particle) then we duplicate the particles to write. That can be a huge jump in memory.

In the longer run, we (I) should really rewrite the i/o code to fish out the particles to write without duplication.

So the handling of stars has changed. when I configure with-hydro=none and run:

 ../../swift --self-gravity --stars --threads=4 -n 16 -y 1 eagle_6.yml

it crashes:

ASAN:DEADLYSIGNAL
=================================================================
==24255==ERROR: AddressSanitizer: SEGV on unknown address 0x154100000011 (pc 0x55fe61281585 bp 0x7ffc5a03c580 sp 0x7ffc5a03bc80 T0)
==24255==The signal is caused by a READ memory access.
ASAN:DEADLYSIGNAL
==24255==AddressSanitizer: while reporting a bug found another one. Ignoring.
ASAN:DEADLYSIGNAL
==24255==AddressSanitizer: while reporting a bug found another one. Ignoring.
ASAN:DEADLYSIGNAL
==24255==AddressSanitizer: while reporting a bug found another one. Ignoring.
    #0 0x55fe61281584 in space_split_recursive /loc/pwda/pdraper/scratch/swift-tests/swiftsim-spare2/src/space_split.c:142
    #1 0x55fe61288cdb in space_split_mapper /loc/pwda/pdraper/scratch/swift-tests/swiftsim-spare2/src/space_split.c:715
    #2 0x55fe6123a08a in threadpool_chomp /loc/pwda/pdraper/scratch/swift-tests/swiftsim-spare2/src/threadpool.c:164
    #3 0x55fe6123a986 in threadpool_map /loc/pwda/pdraper/scratch/swift-tests/swiftsim-spare2/src/threadpool.c:339
    #4 0x55fe61288de7 in space_split /loc/pwda/pdraper/scratch/swift-tests/swiftsim-spare2/src/space_split.c:741
    #5 0x55fe6126ccd5 in space_rebuild /loc/pwda/pdraper/scratch/swift-tests/swiftsim-spare2/src/space_rebuild.c:975
    #6 0x55fe6116fd48 in engine_rebuild /loc/pwda/pdraper/scratch/swift-tests/swiftsim-spare2/src/engine.c:1174
    #7 0x55fe61173944 in engine_init_particles /loc/pwda/pdraper/scratch/swift-tests/swiftsim-spare2/src/engine.c:1722
    #8 0x55fe611350c6 in main /loc/pwda/pdraper/scratch/swift-tests/swiftsim-spare2/examples/main.c:1418
    #9 0x154174bd9bf6 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21bf6)
    #10 0x55fe61127b19 in _start (/loc/pwda/pdraper/scratch/swift-tests/swiftsim-spare2/examples/swift+0x4db19)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /loc/pwda/pdraper/scratch/swift-tests/swiftsim-spare2/src/space_split.c:142 in space_split_recursive

Guessing this is because I don't have a stars model set, but we have stars loaded anyway. Need to stop allowing these to be loaded without a model, or go back to the old behaviour.

changed title from Leaner code active max h collection to Leaner code & active max h collection

changed the description

Thanks. I had not thought of this scenario. The default stellar model is actually runnable so we should keep that and not assume that it's just a place-holder as the hydro-none scheme.

If you fix that, it all looks good to me.

added 2 commits

• 2c5f4649 - Remove very outdated choice of stellar model.
• 7f0c7a8b - Prevent users from running with the stars-none or black-holes-none model.

Compare with previous version

Thanks. For now, I think we can prevent people from running with any of the NONE models. If at some point a use-case emerges for a very basic 'default' model for either stars of black holes, we could create that.

merged

mentioned in commit a6e51aa9