mirochaj / ares Goto Github PK

Hey, I'm trying to produce the global signal base on UVLF, following Mirocha et al 2017:

m17 = ares.util.read_lit('mirocha2017')
sim = ares.simulations.Global21cm(**m17.dpl)
sim.run()
sim.GlobalSignature()

I'm confused about several questions. Firstly, the escape fraction in (13.6, 24.6) band seems to be 0.2 in the litdata/mirocha2017.py, instead of 0.1 as is given in Mirocha et al 2017:
'pop_fesc{0}': 0.2
With 0.2, I have similar result on CMB optival depth to the paper while with 0.1 tau_e is lower.

Secondly, it seems that the emissivity of LW & LyC photons is calculated in rho_L() of ares/populations/GalaxyCohort.py. However, the emissivity of LyC band seems to be 0 here. The line in rho_L() if Emax <= 24.6: N_per_Msun = self.N_per_Msun(Emin=Emin, Emax=Emax) returns 0. This results from the difference between 13.6 and E_LL in line if (Emin, Emax) == (E_LL, 24.6): in N_per_Msun(). However, the result of ionization history seems fine. I'm wondering where the emissivity of LyC band is actually calcaulated?

Btw, the depth of the global trough seems deeper than the results in Mirocha et al 2017. I dont't think it's because of different cosmological parameters?

I'm looking forward to your response! Please forgive if I made any naive mistakes.

Hi, I notice that when running many simulations in a loop, Python garbage collection does not clear memory. This is the minimal reproducible example. memory_leak_min_rep_ex.txt

If you look at the consumed ram with top, it increases with each loop by more than you would expect from saving to the numpy array. The expected behaviour is that all memory that ARES is consuming should be freed after each loop.

The crash occurs when calling ares with xi_XR (or any of the xi parameters). Using xi_XR as an example, it crashes in ares/util/BackwardCompatibility.py, line 114. pf has no 'pop_fstar{1}' key. pf only gets the key if par_supplied('fstar', **kwargs) is true. It crashes when defining the simulation before it is ran.

If you also include fstar as a parameter, backward_compatibility runs twice. The first time, it runs when the simulation is defined okay using the user-inputted fstar. But when the sim is ran, backward_compatibility runs from line 178 in ares/analysis/MultiPhaseMedium.py. I'm pretty sure the pf for the second time is given by SetAllDefaults(), which sets problem_type = 1. That means that the kwargs that backward compatibility uses the second time are given by ProblemType(1), which does not include fstar.

The full error messages are attached.
xi_crash_error_message.txt

Currently, ares.analysis.Global21cm() doesn't work if passed a pathlib.Path object instead of a string. Should be an easy fix; raising issue here just to keep track.

In the tagged versions of the code is it possible to change the version numbers in the setup.py file? Same for the main branch? At least for the main branch of the code and for the tagged version v0.9 the versions in setup.py are both 0.1. Therefore, running pip install . or equivalently python setup.py install on both branches appears to install the same version of the code e.g. running pip show ares returns version 0.1.

This makes version control quite difficult e.g. making sure I'm running the same version of ares on different machines.

Just wanted to share my experience with the versions of required packages for ARES. The code was not working with this combination of packages for me:
Python=3.9.16 numpy=1.24.2 scipy=1.10.1 h5py=3.8.0
If you have the same issue try this:
conda install python=3.10.4 numpy=1.21.5 h5py=3.7.0 scipy=1.7.3

Having trouble resolving the following issue when running the following code

import numpy as np

pars = ares.util.ParameterBundle('mirocha2017:base')

sim = ares.simulations.Global21cm(**pars)
sim.run()

I get the following error message

 File "..../ares/ares/solvers/UniformBackground.py", line 1199, in _flux_generator_generic
    + exp_term * (c_over_four_pi * xsq[ll+1] \
ValueError: operands could not be broadcast together with shapes (2158,) (2159,)

Have you seen this before? Any obvious fixes?

Related to #62. I can run this on one machine but not on another and wondering if this was bug in a particular version of the code... but hard to tell.