Devel #11
Merged
Devel #11
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The builds based on macOS 10.12 (Sierra) have been failing due to long installation times of gcc (ultimately needed by the hdf5 brew package), which doesn't have a bottle for Sierra and needs to be compiled. This compilation takes a long time, and produces a timeout on Travis, who doesn't see output for more than 10 minutes and gives up. Signed-off-by: Rodrigo Tobar <[email protected]>
There was a bug in the effective yield calculation of the evolving yield model.
This was deprecated already in C++11, but I didn't know better back then. I'm replacing it with an inline function instead that results in better readability anyway. Signed-off-by: Rodrigo Tobar <[email protected]>
Boost's cmake package config script is buggy in 1.71 and doesn't respect the Boost_USE_MULTITHREADED setting (see [1] and [2] for details). Let's thus disable using Boost's own config package script and let's stick with cmake's instead. [1] https://stackoverflow.com/questions/58081084/target-boostlibrary-already-has-an-imported-location-link-errors [2] boostorg/boost_install#13 Signed-off-by: Rodrigo Tobar <[email protected]>
- sizes.py now includes a plot of stellar mass vs. BH mass - smf.py now includes a plot of the stellar mass function broken into the contribution from all the stellar components - additional updated include some cosmetic small changes in other python scripts
- the stellar masses come from luminosity in the observations, so h appears as h^2 rather than h^1. This has been correctly accounted for in the revised smf.py. Because hobs=0.7 usually, this makes little difference, but better to do it well! - Added explicity unit h70^2 in stellar masses in Wright+2017 table.
The new model is to be presented in poulton et al., in prep. There are now two possible merger timescale models in shark, these can be set from the merger_timescale_model config option, where the possible options are 'lacey93' (old model) or 'poulton20' (new model).
The python3 package doesn't exist anymore, it's now simply "python", and gets pulled anyway by cxxtest (and on top of that seems to be pre-installed already). The python@2 package is still installed by default though, so it needs to be uninstalled. Also, the hdf5 package is now intalled by default, so let's not try to install it ourselves. Signed-off-by: Rodrigo Tobar <[email protected]>
Added a new merger timescale model
Units were given in a different format to what we were assuming. This has now being corrected in the python script and more info has been added to the tex file.
There were a few unused variables that needed to be gone, a wrong initialisation order for member variables in BasePhysicalModel, and some exceptions not being caught by reference in some of the tests. All pretty minor, and makes the compilation cleaner. Signed-off-by: Rodrigo Tobar <[email protected]>
This used a generator and a distribution that were in no way connected to the seed given in the execution parameters, so it would have introduced unnecessary complexity to the rest of this work. Let's remove this method, it's easy to write back when necessary. Signed-off-by: Rodrigo Tobar <[email protected]>
Signed-off-by: Rodrigo Tobar <[email protected]>
The way we aim to support multi-threaded reproducible runs is by seeding the RNG with a object-dependent value before using them to draw values from the different distributions. This re-seeding, combined with the fact that we use the ID of the particular object the operation is related to, means the values drawn from the distributions don't depend on the order in which we invoke the operations anymore; instead, they now depend on the initial seed (which is potentially set by the user) and the object being operated on. This change means that storing the RNG as a member of the classes that used them is no longer necessary, and it can actually be detrimental when classes are shared by different threads, like in the case of the DarkMatterHaloes base class. To avoid race conditions we thus simply re-create a new RNG each time we want to draw values from one or more distributions, seeding it with the correct value right at construction time. Signed-off-by: Rodrigo Tobar <[email protected]>
Now both types of checks print the same information when they fail, which is useful. Signed-off-by: Rodrigo Tobar <[email protected]>
Warnings are issued with newer versions of h5py, let's avoid them Signed-off-by: Rodrigo Tobar <[email protected]>
This is useful to check that basic things, like IDs, are the same across different runs. Signed-off-by: Rodrigo Tobar <[email protected]>
Both the lognormal and the uniform distributions used by the DarkMatterHalos class (which is shared by multiple threads) do not have any guarantee of being thread-safe, and indeed gcc's implementation of the normal distribution keeps some state. This creates race conditions between multiple threads that might be using them at the same time. To avoid these race conditions we don't store the distributions objects anymore as members of DarkMatterHalos, but create them from scratch each time we need them. This shouldn't be an expensive operation, as neither of them does calculations at construction time; but even if they did they would probably be minor compared to the rest of the computations we do in shark. Signed-off-by: Rodrigo Tobar <[email protected]>
This in turn would mean we can run the multi-threaded reproducibility test in MacOS too, so no platform is left behind for these tests. Signed-off-by: Rodrigo Tobar <[email protected]>
We are adding these in both Travis and AppVeyor. In the case of Travis we are also using all available CPUs. The code has also seen some cleanups, as it was starting to become too repetitive. Signed-off-by: Rodrigo Tobar <[email protected]>
This was from the days when we had to compile our own copy of gsl2, but now we are installing via apt/homebrew so there's no need to specify this anymore. Signed-off-by: Rodrigo Tobar <[email protected]>
On the one hand we were not using it anymore, but even if we need this information again it's already available in the TRAVIS_OSX_IMAGE env variable. Signed-off-by: Rodrigo Tobar <[email protected]>
Let's try not to auto update and auto cleanup homebrew when we install packages; this will hopefully speed up our builds. Signed-off-by: Rodrigo Tobar <[email protected]>
Signed-off-by: Rodrigo Tobar <[email protected]>
This should prevent errors being introduced by developers in the future, but might become a bit of a burden to maintain depending on what compilers decide to declare as a warning. Signed-off-by: Rodrigo Tobar <[email protected]>
This is both in the "Running" section of the documentation, as well as the changelog. Signed-off-by: Rodrigo Tobar <[email protected]>
This new model is based on the calculations of Errani et al. (2015), which modelled the tidal stripping of satellite galaxies in a Milky-Way halo. The outcome of the simulations were fit and here I adopt the best fit for a cuspy core with an r_star/a=0.1. This seems to have the desired effect on the stellar mass function. There is a free parameter which is the minimum allowed threshold of virial mass ratio (Mvir,now/Mvir,infall), which is relevant for galaxies that go from centrals to becoming type II without ever becoming type 1. If the more normal scenario of central->type I->type II takes place, then tidal stripping is more gradual (as it depends on the virial mass loss).
HDF5 C++ -> C API migration
Added as well Driver et al. (2022) MF but using smaller bins than the published paper (data provided by S. Driver).
- Satellite galaxies undergoing jet feebdack that produce enough power to completely switch off their cooling rate contribute to an excess power reservoir which can be used to heat up the halo gas of the central subhalo.
- A lot of new observations added to data/ - New model variations added to data/ to aid the comparison with the published work of Lagos et al. (2018) - many updates to python scripts (and new python scripts added)
- Updated the constraints in optim to use the z=0 SMF of Li&White (2009) and Weaver et al. (2022) at z>0. - reincorporation.cpp: added option that if tau_reinc > 100, assume nothing gets reincorporated
…roctor (in prep.)
Just before writing, jmol and jatom were calculated, but in galaxies with a bulge gas mass > 0, jmol was incorrectly redefined as =0. This problem only affected the writing and not the internal calculation of Shark.
RTD now requires this file to be present to build online documentation pages, so let's provide it with one. Signed-off-by: Rodrigo Tobar <[email protected]>
These were not used and generated warnings in various places. Signed-off-by: Rodrigo Tobar <[email protected]>
I was missing the 200!
Signed-off-by: Rodrigo Tobar <[email protected]>
Inputs had to be updated in the function that calls prepare_data from smf.py
Incorporate PSO analysis scripts that reproduce Proctor (in prep.) figs
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.