SWIFTsim issueshttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/issues2022-07-26T12:56:03Zhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/issues/682Spawn new black holes instead of converting gas particles?2022-07-26T12:56:03ZYannick BahéSpawn new black holes instead of converting gas particles?Should we (optionally, at least) change the way in which black holes are seeded? At the moment, we convert an entire gas particle to a black hole which, however, initially has a true (subgrid) mass that is potentially much lower than the...Should we (optionally, at least) change the way in which black holes are seeded? At the moment, we convert an entire gas particle to a black hole which, however, initially has a true (subgrid) mass that is potentially much lower than the gas particle mass. Instead, we could spawn a new particle (analogous to the procedure for gas particle splitting) with initially zero dynamical mass and seed subgrid mass. With the new nibbling implementation, this particle would then immediately nibble mass from (all) its gas neighbours to adjust its dynamical mass to its subgrid mass.
Advantages:
- Arguably more realistic treatment of low-mass black holes (proper dynamical mass)
- Less instantaneous gas loss when a BH is seeded (at EAGLE std-res, we typically remove 12x as much gas mass as the seed BH subgrid mass)
- Arguably more "SPH-philosophically correct", by drawing seed mass from all SPH neighbours instead of just the one seeding particle.
- More flexibility in where the new BH is born, it does not have to be at the exact location of a gas particle (we have seen that this tends to cause, probably artificial, accretion bursts immediately after seeding)
- Would work equally well for BH seed masses lower or higher than the (typical) gas particle mass.
- Essentially makes dynamical == subgrid mass for all black holes, eliminates analysis confusion / errors (dynamical masses are the "standard" quantity, but less physically meaningful).
Disadvantages:
- Black hole particles with m_dyn << m_gas can cause artificial energy transfer to BHs. However, low-mass black holes are anyway subject to repositioning (although not necessarily with aggressive velocity threshold).
- No guarantee that the new BH has (sufficiently many) gas neighbours, may therefore not be able to grow its dynamical mass. One could argue that we should never seed BHs in such a situation in the first place...?
- Creates more particles -- but typically n_BH << n_gas, so small effect compared to particle increase through gas splitting.
- Would probably need some care to make sure that (temporarily) zero particle mass does not create surprises
- May have unintentional side effects
- Human time needed for implementation and testing
Just putting it out there for consideration / criticism, especially @matthieu, @jborrow, and @rgb.Improved black hole modelYannick BahéYannick Bahéhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/issues/834Discussion: Change chemistry API to enable advection of metallicity (gimzo-mv...2024-02-29T17:19:52ZYolan UyttenhoveDiscussion: Change chemistry API to enable advection of metallicity (gimzo-mvf, shadowswift)For moving mesh hydro and any hydro scheme with non-zero mass fluxes between particles, we should probably advect the metals used for the chemistry. This would be similar to what @mivkov is already doing in GEARRT (see [here](https://git...For moving mesh hydro and any hydro scheme with non-zero mass fluxes between particles, we should probably advect the metals used for the chemistry. This would be similar to what @mivkov is already doing in GEARRT (see [here](https://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/blob/master/src/rt/GEAR/rt_additions.h) and [here](https://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/blob/master/src/rt/GEAR/rt.h#L533-615)).
So following this example, we could add a new function to the chemistry API, e.g. `chemistry_update_mass_fluxes(...)`, which could be called by the relevant hydro schemes at the flux exchange calculations, and apply those fluxes in the `kick`. This would also require extending the `chemistry_part_data` struct to store those fluxes.
# Current status:
The approach discussed here has been implemented for the `EAGLE` chemistry scheme, see !1825 and the `GEAR` and `AGORA` shemes (!1853). The necessary additions (no-ops) have been made to make the `none` and `QLA` chemistry schemes work with all hydro schemes. Any hydro scheme that performs mass fluxes (in master currently only `gizmo-mfv`) will currently not compile with the `GEAR-diffusion` chemistry scheme.
# To-do/questions:
- [ ] Do we need to advect other quantities tracked by the chemistry schemes as well? (e.g. `mass_from_SNIa`, `metal_mass_fraction_from_SNIa`... in `EAGLE`)
- [ ] Adapt `GEAR-diffusion`
- [ ] How to treat diffusion (only relevant for the `GEAR-diffusion` chemistry scheme)?Yolan UyttenhoveYolan Uyttenhove