Known problems installing Exo-Striker on MacOS ( with Anaconda with Version 0.85+)

[3fon3fonov]

For some reason, anaconda/MacOS users have problems compiling with gfortran/numpy.f2py. I have encountered this problem over the years and I do not have any idea why is happening. Perhaps one must ping the Anaconda developers and ask for help.

During installation or when first time powering the Exo-Striker, one usually gets:

ImportError: cannot import name 'rvmod_for' from partially initialized module 'RV_mod.rvmod' (most likely due to a circular import)

The problem is that numpy.f2py cannot create the rvmod*.so library, because the gfortran does not work as it should....

The solution is to get out from the Conda environment:

$ conda deactivate

Then install the tool with your default python3.

Once the rvmod*.so is compiled, I think the Anaconda users can use the Exo-Striker without problems.

[3fon3fonov]

Hi Yingyi, I am moving you issue here:

`Hi Trifon,

I saw the #126 last night. Thank you so much for your quick reply!

The major problem now is that the whole exostriker always crashed suddenly and need reopen after I just started to fix the RV data. And everytime I open the exostriker, these warnings occurs:

0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
qt.qpa.fonts: Populating font family aliases took 145 ms. Replace uses of missing font family "Times" with one that exists to avoid this cost.

Then I tried exostriker -debug, it showed the same warnings.

io:~ yingyicao$ exostriker -debug
0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
qt.qpa.fonts: Populating font family aliases took 145 ms. Replace uses of missing font family "Times" with one that exists to avoid this cost.
jupyter-client==8.6.0
ipykernel==6.27.1
PyQt5==5.15.10
qtconsole==5.5.1
matplotlib==3.8.2
emcee==3.1.4
numpy==1.26.2
scipy==1.11.4
wotan==1.10
jupyter==1.0.0
celerite==0.4.2
pathos==0.3.1
ttvfast==0.3.0
You are running a development version of the Exo-Striker (ver. 0.86).

This version is almost full, but there are still some parts of the tool, which are in a 'Work in progress' state. Please, 'git pull' regularly to be up to date with the newest version.

Here you can get some more information from the tool's workflow, stdout/strerr, and piped results.

I don't know if there is something wrong with the Python(3.11.7 ver.)..
It would be so nice of you to give me some advice to fix it! Thank you so much!

Best,
Yingyi`

[3fon3fonov]

The warnings are not the problem, I also see them on my side. But if the Exo-Striker crashes suddenly without an error is odd. But not so odd for MacOS..... @jan-eberhardt (see #122) also experiences similar problems, but frankly I have no idea how to debug without an error. On my side, everything works fine. I have tested MacOS (intel based), Windows and Linux.

Can you please install your new version and try again?

[Astrocyy]

The warnings are not the problem, I also see them on my side. But if the Exo-Striker crashes suddenly without an error is odd. But not so odd for MacOS..... @jan-eberhardt (see #122) also experiences similar problems, but frankly I have no idea how to debug without an error. On my side, everything works fine. I have tested MacOS (intel based), Windows and Linux.

Can you please install your new version and try again?

Actually I've uninstalled and reinstall it for many times...But still it's good to hear that it is not an error. Thanks!
If that warnings aren't errors at all, I guess it would probably due to the newest version of Python (released on Dec. 4) because when the exostriker crashed, what showed up then is Python crashed! .

[3fon3fonov]

Try Python3.10, and a bit older numpy, say 1.25.X

Also, please report your gfortran version. It may be best if you reinstall your gfortran and use version 11, for instance.

If this does not help, I will try to replicate your system and make some tests.

[Astrocyy]

Try Python3.10, and a bit older numpy, say 1.25.X

Also, please report your gfortran version. It may be best if you reinstall your gfortran and use version 11, for instance.

If this does not help, I will try to replicate your system and make some tests.

My gfortran version is GNU Fortran (GCC) 12.1.0.

[3fon3fonov]

Ok, I have see the problem(s)... The Exo-Striker crashes randomly when RV models are invoked. This boils to the fortran code which we compile with f2py. No clear reason, why this is happening, but is only observed on MacOS with Python 3.11 and gfortran 12+. I will test different versions of gfortran, python3, numpy, etc....

[3fon3fonov]

It seems the rvmod code on macOS is unstable when used with optimization flag -O3.... Things users can try:

$ cd exostriker/lib/RV_mod/rvmod
$ rm *.so
$ python3 -m numpy.f2py -c -m rvmod_for rvmod_for.f95

Then

$ cd ../../../../
$ python3 -m exostriker 

No compilation should be visible in the terminal output, if everything has worked. python3 should be python3.10+

Let me know if your ES has become stable after this innervation. It could be a bit slower, but not by much, I believe.