Problem when using Classy and matplotlib

[mtagliazucchi]

I have a problem with the attached Minimal Working Example test.zip.

In this code I use Classy to compute CMB SDs and PPS by varying first A_s and then n_s. This is done with a unique for cycle. In each run of the cycle I vary only one of the two parameters and make a plot with all the results.

The problem is that the second run of the cycle gives a segmentation fault error (when I call Classy.compute() )

However, if I remove all the part plot part, the error disappear and everything is fine.

Does anyone know where is the problem?

[ShazAlvi]

The same issue was pointed out in #420 but no solution yet.

[ShazAlvi]

I just store the results in a dictionary and plot them at the end. I hope someone finds a more elegant way of doing it.

[mtagliazucchi]

I just store the results in a dictionary and plot them at the end. I hope someone finds a more elegant way of doing it.

Thank you so much for the answer!

[schoeneberg]

Dear @matteotagliazucchi . I downloaded your example script and executed a bunch of times, but could not reproduce the problem. Which CLASS version are you using, and on what system (with what gcc compiler)?

[mtagliazucchi]

Dear @matteotagliazucchi . I downloaded your example script and executed a bunch of times, but could not reproduce the problem. Which CLASS version are you using, and on what system (with what gcc compiler)?

I'm using gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) and the last version of CLASS (3.2.0). When I run that code, the output on the terminal is _Analysis on: A_s \mu = 2.442295e-09 y = 3.875666e-10 \mu = 2.442295e-08 y = 3.875666e-09 \mu = 2.442295e-07 y = 3.875666e-08 Analysis on: ns Segmentation fault (core dumped) The same problem happened to me whenever I run CLASS and plot the results in the same cycle. When the plot part is done outside the cycle where CLASS is computing, everything works fine.

[schoeneberg]

Dear @matteotagliazucchi , I am using precisely the same compiler and CLASS version, and do not get any errors, even after increasing the "pointss" variable to [300,300] instead. Very mysterious! In the past I had this problem always with 3.0, which is why I put a bit of time in making the de-allocation of classy more resilient in the newer classy versions... Please make sure that your print(classy.version) within the same test script does point to the correct 3.2.0. If so, I would be happy if you could also tell me your matplotlib version. Mine is 3.5.3. Maybe updating matplotlib might help (it did so in the past for me for other projects). If all of this doesn't help, I am not sure where to start the debugging, given that I cannot reproduce the problem...

[mtagliazucchi]

Dear @matteotagliazucchi , I am using precisely the same compiler and CLASS version, and do not get any errors, even after increasing the "pointss" variable to [300,300] instead. Very mysterious! In the past I had this problem always with 3.0, which is why I put a bit of time in making the de-allocation of classy more resilient in the newer classy versions... Please make sure that your print(classy.version) within the same test script does point to the correct 3.2.0. If so, I would be happy if you could also tell me your matplotlib version. Mine is 3.5.3. Maybe updating matplotlib might help (it did so in the past for me for other projects). If all of this doesn't help, I am not sure where to start the debugging, given that I cannot reproduce the problem...

Hi! print(classy.version) in the script fails, however running python -c "import classy; print('classy: {}'.format(classy.__version__))" directly i the terminal gives classy: v3.2.0. A similar command for matplotlib gives matplotlib: v3.2.0.

I forgot to say that I'm using python 3.8.3

[schoeneberg]

Dear @matteotagliazucchi , could you try to print(classy.__version__) within the python script? (notice double underscores) It can sometimes happen that the classy version used from within a script is different than that from directly in the terminal. Updating matplotlib might be helpful as well, given that there are several reported segfault crashes with somewhat older matplotlib versions :)

Edit: I realize now that if you put in github, it converts to bold. I was meaning to tell you to print` version__` from the start. sorry about that!

[mtagliazucchi]

Edit: I realize now that if you put in github, it converts to bold. I was meaning to tell you to print version__ from the start. sorry about that!

No problem! Still, the output of that command is v3.2.0

Previously, I typed the wrong matplotlib version, which was 3.4.3 and not 3.2.0. I updated it to 3.6.2, but still the segmentation fault (core dumped) error is present.

Anyway, thank you so much for your help!

[mtagliazucchi]

Dear @schoeneberg, I've just discovered a curious thing.

I've wrote a Jupyter Notebook with exacty the same code and it works fine! Maybe this could help in finding the problem.

I attach the jupyter notebook.

Cheers test.zip

[schoeneberg]

Dear @matteotagliazucchi : That it works in the jupyter notebook but not in the default terminal indicates to me that different versions of python are being used, and there's a mismatch somewhere. It could be that you have compiled classy with python of a given version, but are running it on python of another version. E.g. compiled with python2 and executing with python3.

I would suggest: Updating cython (0.29 or above would be good) Recompiling classy from scratch and explicitly putting the python version you are going to execute the script with (make clean; PYTHON=pythonXXX make -j) where the XXX is the version of python you are executing the final script with (e.g. python --version from your terminal).

[adematti]

Hi, in case that's helpful I got a similar issue a while ago (dots in figures of the generated parameter file were interpreted as commas, or vice-versa), and it got fixed with: export LC_NUMERIC="C"

[mtagliazucchi]

Hi, in case that's helpful I got a similar issue a while ago (dots in figures of the generated parameter file were interpreted as commas, or vice-versa), and it got fixed with: export LC_NUMERIC="C"

Thank you so much! Maybe this and the comment reguarding the dictionary can be valid solutions. I then close this issue.