SWIFTsim merge requestshttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests2016-06-13T16:59:26Zhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/106[WIP] Gizmo unification2016-06-13T16:59:26ZMatthieu Schaller[WIP] Gizmo unification@nnrw56 and @bvandenbroucke I need your opinion on this.
The idea here is to merge back Bert's GIZMO branch with the rest of the code. At the moment, the master code is able to switch smoothly between SPH implementations that only req...@nnrw56 and @bvandenbroucke I need your opinion on this.
The idea here is to merge back Bert's GIZMO branch with the rest of the code. At the moment, the master code is able to switch smoothly between SPH implementations that only require two loops over neighbours. This switch is done simply by changing the define in const.h. Note that in the longer run, that should be done in the configure script.
All the tasks are now agnostic of the hydro variation being used and simply call the right hydrodynamic functions, which are brought it at compile time via the file hydro.h.
Now, in the case of GIZMO, there are three loops over neighbours, meaning that the changes are not just restricted to runner.c but that more tasks have to be added.
In order to accommodate for this and to be more generic, I propose this modification which gives a framework to construct simply any number of loops over neighbours and the corresponding number of ghost tasks.
To be even more generic, I have created two kind of loops the "gather" loops (SPH terminology) which correspond to DOPAIR1 in swift and the "symmetric" loops corresponding to DOPAIR2. Any particle-based implementation would need N gather loop followed by M symmetric loops (Gadget-2: N=M=1, Gizmo: N=2, M=1). In principle, there exist cases with (N=0, M=1) but that would be a very bad implementation. I know one variant of SPH with (N=3, M=1) but none with M>1.
As a consequence there will N+M-1 ghost tasks.
The first changes are:
- Create more generic names for the tasks.
- Create an array of these tasks for each cell.
- In 'runner_main()', implement a better way of switching between task subtypes.
Then comes the large bit.
In engine.c, we have have the function 'engine_maketask()' that does many things (ignoring gravity for now). It:
1. creates the first loop over neighbours
2. creates the ghosts
3. duplicates the first loop and create the dependencies.
So, as a first step, I have created sub-functions that correspond to these operations (same for gravity which corresponds to more or less empty functions).
I have then made the last two functions more generic. They will now create a generic number of tasks and create the correct number of ghosts and links for the given hydro scheme.
This comes at the cost of having some pre-processor magic, which is a bit ugly but users willing to add more loops should quickly understand what is going on.
Note that the gizmo code in that branch is still an empty shell. It compiles but won't do anything. Let's focus on the architecture for now.
Similarly, I have not done the corresponding work for the MPI tasks but it should be a straight-forward extension.
So, my question to both of you: What do you think of this way of doing things ? I really would like to bring Bert and GIZMO back in the picture before attacking gravity such that we can make it as generic as possible.
Matthieu SchallerMatthieu Schallerhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/272Added README files to examples2016-10-26T09:31:19ZStefan Arridgestefan.arridge@durham.ac.ukAdded README files to examplesAlso made a couple of small changes to the plotting scriptsAlso made a couple of small changes to the plotting scriptsMatthieu SchallerMatthieu Schallerhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/281Fix cooling timestep2016-11-05T17:40:16ZStefan Arridgestefan.arridge@durham.ac.ukFix cooling timestepMade changes to the 'const lambda' cooling routine.
Cooling timestep is limited by 'cooling_timestep_mult' parameter
Particle cannot cool by more than half its internal energy in one timestep
Particles which are close to the energy f...Made changes to the 'const lambda' cooling routine.
Cooling timestep is limited by 'cooling_timestep_mult' parameter
Particle cannot cool by more than half its internal energy in one timestep
Particles which are close to the energy floor ignore the cooling timestep.Matthieu SchallerMatthieu Schallerhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/342[WIP] Implementation of a timestep limiter for the hydro schemes2017-07-10T14:20:21ZMatthieu Schaller[WIP] Implementation of a timestep limiter for the hydro schemesImplement missing SPH physicsMatthieu SchallerMatthieu Schallerhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/451WIP: Adding Grackle cooling to Swift2017-11-02T15:23:09ZLoic HausammannWIP: Adding Grackle cooling to SwiftInitial discussion in #379Initial discussion in #379Grackle CoolingLoic HausammannLoic Hausammannhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/478[WIP] Timestep limiter for hydrodynamics2018-03-28T19:18:06ZMatthieu Schaller[WIP] Timestep limiter for hydrodynamicsThis implements #196.
We create an extra loop after the second kick where we verify that particles do not have neighbours with vastly different signal velocities. If they do, we wake up the inactive particle.
Currently works with...This implements #196.
We create an extra loop after the second kick where we verify that particles do not have neighbours with vastly different signal velocities. If they do, we wake up the inactive particle.
Currently works with all the hydro schemes as well as with gravity.
Missing for now:
- Deal with MPI.Peter W. DraperPeter W. Draperhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/482WIP: Resolve "Generic cache construction for all flavours of SPH"2018-01-05T16:35:32ZJames WillisWIP: Resolve "Generic cache construction for all flavours of SPH"Closes #295Closes #295Vectorization of all the core SPH taskshttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/511Keplerian ring test2018-03-07T14:31:51ZJosh BorrowKeplerian ring testThe Keplerian Ring Test.
@pdraper I have been having some issues squashing commits in this branch; could you please check this out before merging in 197 separate commits? There must be something that I am missing but whenever I try to s...The Keplerian Ring Test.
@pdraper I have been having some issues squashing commits in this branch; could you please check this out before merging in 197 separate commits? There must be something that I am missing but whenever I try to squash I get a bunch of conflicts.
An example plot:
![plot](/uploads/28e27c7246ef6d642c316cc839e6fb1d/plot.png)Peter W. DraperPeter W. Draperhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/530WIP: Add convergence scripts2018-04-23T20:52:37ZJosh BorrowWIP: Add convergence scriptsThis is the convergence script that I used for EWASS. It produces the following plot:
![sod_shock_master_scaling_with_time](/uploads/d422fce28a6dcc47e46e519baa89fa43/sod_shock_master_scaling_with_time.png)
Let me know if you don't ...This is the convergence script that I used for EWASS. It produces the following plot:
![sod_shock_master_scaling_with_time](/uploads/d422fce28a6dcc47e46e519baa89fa43/sod_shock_master_scaling_with_time.png)
Let me know if you don't think it's appropriate to be added in this way.Matthieu SchallerMatthieu Schallerhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/567[WIP] Add Pressure-Energy with Morris and Monaghan artificial viscosity2018-08-08T10:58:05ZJosh Borrow[WIP] Add Pressure-Energy with Morris and Monaghan artificial viscosityThis includes a new scheme, `pressure-energy-monaghan` that includes a variable artificial viscosity.
More information is available here:
http://adsabs.harvard.edu/abs/1997JCoPh.136...41M
This still needs documenting fully, but I ...This includes a new scheme, `pressure-energy-monaghan` that includes a variable artificial viscosity.
More information is available here:
http://adsabs.harvard.edu/abs/1997JCoPh.136...41M
This still needs documenting fully, but I think it is probably a good idea to merge this sooner rather than later to avoid divergence.
Note that we actually update the artificial viscosity half a time-step too "late" -- this does not seem to have a significant effect.
This passes all of the current hydro tests, and shows a significant improvement, particularly with respect to the width of the distributions.
See attached the `SedovBlast_3D`.
![pressure-energy-monaghan_SedovBlast_3D_5_3D](/uploads/096fc18f138fb222855ace21c947a576/pressure-energy-monaghan_SedovBlast_3D_5_3D.png)
One minor issue is that this makes performance on the Evrard collapse marginally worse; the distribution is moved around a bit.
![pressure-energy-monaghan_EvrardCollapse_3D_8_3D](/uploads/c1e81ccc98853c27fceb4b1c42febf4c/pressure-energy-monaghan_EvrardCollapse_3D_8_3D.png)Add ANARCHY-SPHMatthieu SchallerMatthieu Schallerhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/652WIP: Stars sort2018-11-06T09:11:39ZLoic HausammannWIP: Stars sortStill need to work on it, the code seems too slow.Still need to work on it, the code seems too slow.Stellar physicsLoic HausammannLoic Hausammannhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/749Added diffusion (Diffusion_1D) test.2019-03-08T08:30:50ZJosh BorrowAdded diffusion (Diffusion_1D) test.This adds a new hydrodynamics test for investigating the diffusion schemes.This adds a new hydrodynamics test for investigating the diffusion schemes.Add ANARCHY-SPHMatthieu SchallerMatthieu Schallerhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/756WIP: Eagle SNII feedback2019-03-16T15:58:40ZMatthieu SchallerWIP: Eagle SNII feedbackMatthieu SchallerMatthieu Schallerhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/833[WIP] EAGLE - Sampled stellar evolution2019-07-29T08:06:10ZMatthieu Schaller[WIP] EAGLE - Sampled stellar evolutionCopy over a feature of the EAGLE model:
- Stars carry the time of their last enrichment.
- Stars above a certain age do enrichment only every N steps.
- Loops over stars' neighbours are not run for stars not doing enrichment.Copy over a feature of the EAGLE model:
- Stars carry the time of their last enrichment.
- Stars above a certain age do enrichment only every N steps.
- Loops over stars' neighbours are not run for stars not doing enrichment.ParisMatthieu SchallerMatthieu Schallerhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/923Alternative definition of the neighbour number2019-09-15T13:17:26ZMatthieu SchallerAlternative definition of the neighbour numberBetter way to implement the alternative definition of the neighbour number.Better way to implement the alternative definition of the neighbour number.Josh BorrowJosh Borrowhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/924Alternative definition of the number of neighbours2019-09-18T15:50:19ZMatthieu SchallerAlternative definition of the number of neighboursBetter way to implement the alternative definition of the neighbour number.Better way to implement the alternative definition of the neighbour number.Josh BorrowJosh Borrowhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/933Add Dehnen & Aly E0 density correction2019-12-13T13:34:38ZJosh BorrowAdd Dehnen & Aly E0 density correctionThis MR adds the density correction for the Wendland-CX kernels in 3D, as specified in Dehnen & Aly Equation 19. It required:
+ Adding new variables for every kernel in `kernel_hydro.h`
+ Adding a new parameter file parameter ``SPH:use_...This MR adds the density correction for the Wendland-CX kernels in 3D, as specified in Dehnen & Aly Equation 19. It required:
+ Adding new variables for every kernel in `kernel_hydro.h`
+ Adding a new parameter file parameter ``SPH:use_epsilon_density_correction``
+ Changing the function signature of ``hydro_end_density`` to include a new parameter (a single float passed by value)
+ Updating the relevant sections of the tests and `runner`
+ Adding the relevant documentation.
It seems to make very little difference to the dynamics; here's the SodShock_3D with and without:
With correction
![SodShock](/uploads/13a7c1b58e57f61e62e5651c86d4d83d/SodShock.png)
Without correction
![sodshock_no_correction](/uploads/6f087a6df4dc4991f09585f6b358bb1d/sodshock_no_correction.png)
but I see no reason _not_ to use it in those cases. Either way, I've set it to default to 'off'. I am currently running more tests to see where (if ever) it makes a difference.Add ANARCHY-SPHMatthieu SchallerMatthieu Schallerhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/1037WIP: Resolve "Planetary physics documentation"2020-03-13T14:59:57ZJacob Kegerreisjacob.kegerreis@durham.ac.ukWIP: Resolve "Planetary physics documentation"Closes #659Closes #659https://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/1099WIP: More eos2020-07-03T07:04:15ZJacob Kegerreisjacob.kegerreis@durham.ac.ukWIP: More eosAdd more planetary equations of state: ANEOS materials with SESAME-style tables and Tillotson basaltAdd more planetary equations of state: ANEOS materials with SESAME-style tables and Tillotson basaltMatthieu SchallerMatthieu Schallerhttps://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/1197Fix final snapshot properties2020-10-22T17:04:37ZMatthieu SchallerFix final snapshot propertiesThe final dump of stats/snapshot/VR should have a drift but not a drift that initialises the particles. This was triggered by the jenkins suite.
@jborrow somehow, we never caught that the final snapshot had wrong values for things that ...The final dump of stats/snapshot/VR should have a drift but not a drift that initialises the particles. This was triggered by the jenkins suite.
@jborrow somehow, we never caught that the final snapshot had wrong values for things that get initialised in the drift and hence zeroed. Like the densities. Is that really true?
Now that the default is SPHENIX, the code is actually crashing on the final dump as we try to gather entropies in the stats and this leads to a division by 0.
Did we always have garbage densities in the final snapshots (not with an output list) or does that occur only if we use a fixed number of steps (`-n`)?Josh BorrowJosh Borrow