Regarding the Star formation History of subhalos

[AbdulGani786]

I am using Galacticus to extract Star formation History.

1. I have used the testsuite test-star-formation-histories-adaptive.xml parameter file. Which resulted in the generation of 60 merger trees.
2. Using "noIsIsolated", I figured which are sub-halos and which are main halos.
3. My main question is should we observe the Star formation History in the subhalos too? All but one sub-halos have all entry =0 as the output under the starFormationHistory section.
4. My second question is Should we observe the star formation history in all halos ? There are few of the main halos with all the entry =0 as the output under the starFormationHistory section.

Again to summarize, I want to ask does galacticus also provide the SFH values of the sub-halos too? Also, does all the main halos posses SFH values ?

[abensonca]

Yes - in general all halos and subhalos will have a non-zero SFH. The reason you're seeing lots of zero entries is related to the specific model that you're running. The test-star-formation-histories-adaptive.xml parameter file runs a set of mostly low resolution merger trees. Specifically, it sets a distribution of tree masses as follows:

  <mergerTreeBuildMasses value="sampledDistributionUniform">
    <massTreeMinimum value="1.0e10"/>
    <massTreeMaximum value="1.0e13"/>
    <treesPerDecade value="20"/>
  </mergerTreeBuildMasses>

which results in tree mass being distributed between 1e10 and 1e13M☉ according to the halo mass function. Since the halo mass function is steeply rising toward lower masses, most of the trees will have masses close to 1e10☉.

Then, the file does not specify a mass resolution for the trees, so it will default to 5e9☉. So, most of the trees will be barely resolved - and therefore do not form any stars.

Depending on the science question you want to answer you'll probably want to change the distribution of masses to run, and maybe also the resolution, e.g.:

<mergerTreeMassResolution value="fixed">
 <massResolution value="1.0e9"/>
</mergerTreeMassResolution>

and check that you are producing the range of halo and galaxy masses that are of interest to you, and that they are sufficiently well resolved to give converged answers.

[AbdulGani786]

Thank you for the reply. But it seems that increasing resolution only results in producing more number nodes in the merger trees. Still I am encountering majority of sub-halos to be with 0 entry with no stellar mass present in them and thus no star formation has happened in them ( till now I have not only increased the resolution till 1e8). Also, I want to keep the masses of the halos of merger trees to be randomly evenly distributed so I want to keep the merger Tree Distribution as
<mergerTreeBuildMasses value="sampledDistributionUniform">

I tried working with different starFormationHistory class like Metallicity Split and inSitu.
In metallicitySplit as the output is given in terms of whole merger tree, majority of merger trees's diskSFH (Star formation history stellar masses of the disk) entries were zero.

Also, I really needed help with inSitu starFormationHistory class. I have used the same parameter file as above with the change in
starformation history as
<starFormationHistory value="inSitu"/> (all other parameters to detault)
and increase in the resolution as
<mergerTreeMassResolution value="fixed">
<massResolution value="1.0e8/>
</mergerTreeMassResolution>
and I am getting these two errors as "Galacticus experienced a segfault - will try to flush data before exiting.
=> Error occurred in thread " and "Fatal error:
unable to test data type for dataset 'time'
Occurred at:
function:IO_HDF5_Is_Reference
module:IO_HDF5
file:utility.IO.HDF5.F90 [line 16858]
=> Error occurred in thread "

[abensonca]

Can you explain in more detail what science problem you're trying to address? Many low mass subhalos will have zero stellar mass if you run a model that does not include the relevant physics to allow them to form stars. For example, cooling may be inefficient (or cut off) in low mass halos so there will be no stars formed in them. That sounds like what is happening here. The parameter file you are using contains:

  <accretionHalo value="simple">
    <redshiftReionization value="10.5"/>
    <velocitySuppressionReionization value="35.0"/>
  </accretionHalo>

which will stop all accretion of baryons into halos with virial velocity below 35km/s after z=10.5 - that will suppress star formation in most low mass halos.

The problem with <starFormationHistory value="inSitu"/> is a bug in Galacticus. I've fixed this now and pushed the fix to the Galacticus GitHub repo. If you're building Galacticus from source you can use git pull to update and the recompile. If you're using the pre-compiled binary Galacticus.exe then you'll need to wait for this to be rebuilt with the new fix - that should be done later today. You can monitor the workflow that is building and testing this fix here - once the spinning yellow circle:

changes to a green check then the new executable should be ready.

[AbdulGani786]

we are basically planning to use our own post-processing techniques on the output provided by the galacticus-semi-analytical model. Plotting SFH, and SEDs and then post-processing it. So, we want to extract star formation Histories of the galaxies, using galacticus. This is what we have in mind till now. Later we also think to compare our results with the observations too.

[abensonca]

In that case probably you don't want to increase the resolution of the merger trees - as you'll just get low mass halos with zero SFHs. If you need a larger sample then I would simply generate more trees, and ignore any galaxies that have zero stellar mass and SFH.

If there are specific observations you want to compare to later then you'll probably need to adjust the range of tree masses and resolutions that you use to ensure that you generate galaxies that are comparable to the observed ones.

[abensonca]

Yes, the star formation rates will be in units of Msun/Gyr.

…

On Monday, July 17, 2023 3:02:40 AM PDT AbdulGani786 wrote: thank you for your reply and suggestions. I just want to clarify the output of the above parameter file. Since,the time binning is in Gyr. The final star formation rate is represented M_☉/ GYr right ?

-- * Andrew Benson: https://abensonca.github.io * Galacticus: https://bitbucket.org/abensonca/galacticus

[AbdulGani786]

is the scale height value=0.137 fixed for all galaxies. And are the units same as radial scale ie Mpc.

[abensonca]

The scale height is defined as a fraction of the radial scale length. So, a value of 0.137 means that $h_z = 0.137 r_\mathrm{d}$ where $h_z$ is vertical scale height, and $r_\mathrm{d}$ is the radial scale length. This value is fixed for all galaxies. You can change the value in the massDistribution used for the disk component in your parameter file, e.g.:

  <componentDisk value="standard">
    <toleranceAbsoluteMass value="1.0e-6"/>
    <massDistributionDisk value="exponentialDisk">
      <dimensionless value="true"/>
      <scaleHeight value="0.2"/>
    </massDistributionDisk>
  </componentDisk>

would set the scale height to be t $h_z = 0.2 r_\mathrm{d}$.

[AbdulGani786]

sorry for this confusion. So:

1. R_disk which we are getting as an output is in terms of radialScale. And since the default value of [scaleRadius]=1e0. R_disk would simply be in Mpc.
2. And for each galaxy. h_z =0.137 r_d. So h_z=0.137 (since default value of r_d=1).
   or vertical scale height = 0.137 R_disk. (And it would be different for each galaxies which makes more sense).

PS: the reason for all this confusion are these two texts mention in the galacticus_physics.pdf
"[scaleRadius] (real; 0,1) {1.0e0} The scale radius of the exponential disk profile." (parameter of exponential disk)
"radius The radial scale length of the disk, Rdisk [diskRadius]." (output of the merger tree disk component)

So, why are we giving the same thing as parameters if we want to get it as an output?
Since I am calculating the mass density so I need characteristic radius of each galaxies and vertical height of each galaxy.
In order to compute the number density of hydrogen. So I have to be very careful with the units.
thank you.

[abensonca]

The output property diskRadius is in units of physical Mpc - this corresponds to the statement in the documentation "radius The radial scale length of the disk, Rdisk [diskRadius]"

It might help to understand how this works internally. The massDistribution for disks that you specify in the parameter file is defined in a dimensionless way - it always has a radial scale radius of 1, and a total mass of 1 (no units to either of these). And you can specify a scaleHeight for it which is also dimensionless - the default is 0.137 but you can set whatever you want.

Internally, each galaxy has a radial scale length $r_\mathrm{d}$ (in Mpc) and a mass, $M_\mathrm{d}$ (in $\mathrm{M}\odot$). The dimensionless massDistribution is then scaled by these quantities - since it had unit mass and radius initally, it will now have mass $M\mathrm{d}$ and radius $r_\mathrm{d}$. And, therefore, it will have a physics scale height of $0.137 r_\mathrm{d}$ (in Mpc).

So, the output quantity diskRadius is always in Mpc - you don't specify it in the parameter file - it is computed internally. The scale height of every disk will always be $f r_\mathrm{d}$ where $r_\mathrm{d}=$diskRadius and $f$ is equal to whatever value you set scaleHeight to in the parameter file (or 0.137 by default if you do not set a value in the parameter file).

So, why are we giving the same thing as parameters if we want to get it as an output?

I don't understand what you mean here - can you explain?

[AbdulGani786]

I got it. Thank you. You explained everything which I had asked in the above comment.

[AbdulGani786]

Hello sir, as mentioned above I am using test-star-formation-histories-adaptive.xml parameter file. We used our post processing technique to generate the SEDs of the galaxies and plotted the Luminosity function. Now when we compare it with observational value the luminosity of the galaxies are not matching with the observational values. The maximum value of vF_v of the galaxy we are getting is in the range of 10^7 orders. I guess that because we are not producing the galaxies which represent the original galaxies.
In order to not select dwarf galaxies, I have only take galaxies with stellar mass > 10^8 Solar mass and disk radius greater than 1kpc. I thought this would sufficiently provide me with galaxies which would have adequate star formation. Also I am observing galaxies at z=0.1 . Am I fundamentally producing wrong galaxies? Or what is the reason of the so less star formation. I am really stuck at this any help or insight would be helpful.

[abensonca]

I would need much more information to be able to help you with this. What data are you comparing to? Do you have plots of the SEDs? Are you sure that the problem is in Galacticus, or could it be in your postprocessing code (in which case it's unlikely that I'd be able to help you)?

I would start by checking whether the galaxies you select are similar in mass and star formation rate to the observed galaxies. If they are, then I would guess that any problem is occurring in your postprocessing code.

I'd also suggest checking that your copy of Galacticus is fully up to date as there have been some recent fixes to the star formation history code.

You could also consider outputting the SEDs directly from Galacticus to see if they agree with the results from your postprocessing. You can output SEDs by adding the following to the list of nodePropertyExtractors:

<nodePropertyExtractor value="SED">
   <component value="disk"/>
   <frame value="reset"/>
   <wavelengthMinimum value="1000.0"/>
   <wavelengthMaximum value="10000.0"/>
   <resolution value="100.0"/>
</nodePropertyExtractor>
<nodePropertyExtractor value="SED">
   <component value="spheroid"/>
   <frame value="reset"/>
   <wavelengthMinimum value="1000.0"/>
   <wavelengthMaximum value="10000.0"/>
   <resolution value="100.0"/>
</nodePropertyExtractor>

which will output SEDs for disk and spheroid components. You can adjust the min/max wavelengths and resolution as needed (using a resolution of -1 will result in the highest possible resolution allowed by the stellar population synthesis models).