SWIFTsim issueshttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/issues2021-07-25T10:58:55Zhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/issues/572Memory stuff2021-07-25T10:58:55ZPedro GonnetMemory stuffThinking out loud (and reminding myself) about small changes that improve memory and/or code sanity.
These are all quite concrete suggestions that I will try to implement (or am currently implementing) in the following week or two, so i...Thinking out loud (and reminding myself) about small changes that improve memory and/or code sanity.
These are all quite concrete suggestions that I will try to implement (or am currently implementing) in the following week or two, so if you see any improvements or problems with any of them, or have changes you would like added to the list, please let me know!
* **Smarter send/recv placement** i.e. don't include sub-cell tasks in the definition of the super-cell. This is a bit tricky since it changes quite a bit of the logic regarding activating send/recvs. This is ongoing in the branch `smarter_sends`.
* **Top-level cells** should be an array of pointers, not an array of cells. For very large simulations this is problematic if we have a very fine top-level grid but only very few local/foreign cells we are interested in. Might cause some problems with gravity.
* **Merge send/recv tasks**, no single cell with both send and receive data, so these task types are either/or. Also, merge all send/recv types into their own linked lists. This is ongoing in the branche `collapse_send_recv_tasks`.
* **Why `struct link`?** Why not just add a `next`-pointer to a task and be done with it? What the hell was I thinking when I implemented this anyway?ParisPedro GonnetPedro Gonnet