Public repository of the Cosmic Linear Anisotropy Solving System (master for the most recent version of the standard code; GW_CLASS to include Cosmic Gravitational Wave Background anisotropies; classnet branch for acceleration with neutral networks; ExoCLASS branch for exotic energy injection; class_matter branch for FFTlog)
Dear all,
I apologize in advance if the question is trivial or inappropriate.
I am working with a modified version of CLASS.
Essentially the modification consists in adding two new fields (called respectively s_lrf and dm_lrf), their background and perturbation quantities.
The code runs.
However, there are leaks that prevent a successful run of MCMC code (in particular, the chains are killed with a message saying that the requested memory was all filled)
I tried using valgrind to understand the error, and I attach some of the logs.
In particular, I tried several .ini configurations, noticing the following:
-whenever I run in a "lcdm" configuration (using the default .ini of CLASS, without initializing the lrf variables), valgrind does not complain much. (this is seen in the attached log file called class_git_exp_valgrind_full_leak.txt)
-whenever I run with an .ini the initialize the variables using the sync gauge, there are several errors. (this is seen in the attached log file called class_git_sync_valgrind_full_leak.txt)
-running in newtonian is even worse: there are much more leaks and the indicated lines comes from the perturbations.c file. However this is not the issue that caused the MCMC to stop given that I always ran in sync gauge. So since it is a different problem apparently I will not further discuss it.
I tried to look at what happen in the specific lines but it seems (at least to a beginner eye like mine) all the arrays are freed correctly.
In particular, the code lines indicated in the most common error (the background related one) of the class_git_sync_valgrind_full_leak.txt log are the following:
The lines that precede it (the input_read_parameters one) is inside an if with a lrf flag inside input_read_parameters_species
What I think is going on is that somehow the initialization of the new "lrf" variables make the background arrays not freed after a call of the background solver.
The index seems fine (it is increased when the lrf fields are present).
So I do not really understand why by following the "standard" CLASS flow the arrays are not freed by the free calls at the end of the function background_solve, in particular the lines:
Dear all, I apologize in advance if the question is trivial or inappropriate.
I am working with a modified version of CLASS. Essentially the modification consists in adding two new fields (called respectively s_lrf and dm_lrf), their background and perturbation quantities.
The code runs. However, there are leaks that prevent a successful run of MCMC code (in particular, the chains are killed with a message saying that the requested memory was all filled)
I tried using valgrind to understand the error, and I attach some of the logs. In particular, I tried several .ini configurations, noticing the following: -whenever I run in a "lcdm" configuration (using the default .ini of CLASS, without initializing the lrf variables), valgrind does not complain much. (this is seen in the attached log file called class_git_exp_valgrind_full_leak.txt) -whenever I run with an .ini the initialize the variables using the sync gauge, there are several errors. (this is seen in the attached log file called class_git_sync_valgrind_full_leak.txt)
-running in newtonian is even worse: there are much more leaks and the indicated lines comes from the perturbations.c file. However this is not the issue that caused the MCMC to stop given that I always ran in sync gauge. So since it is a different problem apparently I will not further discuss it.
I tried to look at what happen in the specific lines but it seems (at least to a beginner eye like mine) all the arrays are freed correctly.
In particular, the code lines indicated in the most common error (the background related one) of the class_git_sync_valgrind_full_leak.txt log are the following:
class_alloc(pba->tau_table,pba->bt_size sizeof(double),pba->error_message); class_alloc(pba->z_table,pba->bt_size sizeof(double),pba->error_message); class_alloc(pba->loga_table,pba->bt_size * sizeof(double),pba->error_message);
class_alloc(pba->d2tau_dz2_table,pba->bt_size sizeof(double),pba->error_message); class_alloc(pba->d2z_dtau2_table,pba->bt_size sizeof(double),pba->error_message);
class_alloc(pba->background_table,pba->bt_size pba->bg_size sizeof(double),pba->error_message); class_alloc(pba->d2background_dloga2_table,pba->bt_size pba->bg_size sizeof(double),pba->error_message);
The lines that precede it (the input_read_parameters one) is inside an if with a lrf flag inside input_read_parameters_species
What I think is going on is that somehow the initialization of the new "lrf" variables make the background arrays not freed after a call of the background solver.
The index seems fine (it is increased when the lrf fields are present). So I do not really understand why by following the "standard" CLASS flow the arrays are not freed by the free calls at the end of the function background_solve, in particular the lines:
free(pvecback); free(pvecback_integration); free(used_in_output);
I attach the valgrind logs and I hope the question is precise enough
class_git_sync_valgrind_full_leak.txt class_git_exp_valgrind_full_leak.txt