Skip to content
This repository has been archived by the owner on Jun 24, 2022. It is now read-only.

_pydstool_jl_hack - where is this? #13

Open
jacobsca opened this issue Oct 29, 2018 · 12 comments
Open

_pydstool_jl_hack - where is this? #13

jacobsca opened this issue Oct 29, 2018 · 12 comments

Comments

@jacobsca
Copy link

I'm trying to use PyDSTool in DifferentialEquations...but it won't load. I get this long red error message that says

ERROR: InitError: PyError (PyImport_ImportModule

The Python package _pydstool_jl_hack could not be found by pyimport. Usually this means
that you did not install _pydstool_jl_hack in the Python version being used by PyCall.

Any clues how to fix this?? I done some web crawling but cannot seemingly find a helpful answer...

@ChrisRackauckas
Copy link
Member

I'm not sure how to fix this. It's pointing to the monkey patching here: https://github.com/JuliaDiffEq/PyDSTool.jl/blob/master/src/_pydstool_jl_hack.py . @tkf was the fix tagged?

@tkf
Copy link
Contributor

tkf commented Nov 1, 2018

@ChrisRackauckas No release AFAICT:
https://github.com/robclewley/pydstool/releases
https://pypi.org/project/PyDSTool/#history
https://anaconda.org/conda-forge/pydstool

Actually this "should not" happen. But I realized that it can happen if pydstool or scipy is not installed. I wasn't handling such case properly in __init__ of PyDSTool.jl.

@jacobsca Maybe you are not using Conda.jl? What is the output of the following commands?:

versioninfo()
using Pkg
Pkg.status()
using PyCall  # if it errors, try Pkg.add("PyCall") first
@show PyCall.conda
@show PyCall.pyprogramname

If PyCall.conda is false or PyCall.pyprogramname points to Python 3, you can try

using Pkg
ENV["CONDA_JL_VERSION"] = "2"
ENV["PYTHON"] = ""
Pkg.build("PyCall")  # let PyCall.jl use Conda.jl
exit()

to let Conda.jl download miniconda2 and then install pydstool in it.

@jacobsca
Copy link
Author

jacobsca commented Nov 2, 2018 via email

@ChrisRackauckas
Copy link
Member

Radau and Dopri needs a special install for PyDSTool that we don't do by default. These need to be compiled separately and something.

@HenriLaurie
Copy link

I think this is still unresolved. In my course at the moment we can't use PyDSTool because of both Python 2.x and Python 3.x being installed on the system. PyCall seems to be defaulting to Python 3.x and then using PyDSTool fails.

And often but not always it asks for _pdstool_jl_hack to be installed.

It isn't clear to me what we should do ... I am reluctant to play with ENV() because I worry it will contaminate other uses of PyCall.

@tkf
Copy link
Contributor

tkf commented Mar 26, 2019

I think using Python 2 is the only option unless you want to use pydstool master. You need to use ENV for it since it is the official way to configure Python used for PyCall https://github.com/JuliaPy/PyCall.jl#specifying-the-python-version (i.e., ENV["PYTHON"] = "python2"; using Pkg; Pkg.build("PyCall")). As you worried, this will "contaminate" the PyCall setup because there is no way to use Python 2 without switching to it entirely.

@LolianSh
Copy link

Hi, I am facing a similar problem.

I can add and build the PyDSTool.jl but when I test it this what I get:

[ Info: Installing PyDSTool via the Conda pydstool package...
[ Info: Running `conda config --add channels conda-forge --file /Users/loliansh/.julia/conda/3/condarc-julia.yml --force` in root environment
Warning: 'conda-forge' already in 'channels' list, moving to the top
[ Info: Running `conda install -y pydstool` in root environment
Collecting package metadata (current_repodata.json): done
Solving environment: done

# All requested packages already installed.

┌ Warning: `getindex(o::PyObject, s::AbstractString)` is deprecated in favor of dot overloading (`getproperty`) so elements should now be accessed as e.g. `o."s"` instead of `o["s"]`.
│   caller = __init__() at PyDSTool.jl:23
└ @ PyDSTool ~/.julia/packages/PyDSTool/T2R3A/src/PyDSTool.jl:23
ERROR: InitError: PyError (PyImport_ImportModule

The Python package _pydstool_jl_hack could not be found by pyimport. Usually this means
that you did not install _pydstool_jl_hack in the Python version being used by PyCall.

PyCall is currently configured to use the Julia-specific Python distribution
installed by the Conda.jl package.  To install the _pydstool_jl_hack module, you can
use `pyimport_conda("_pydstool_jl_hack", PKG)`, where PKG is the Anaconda
package the contains the module _pydstool_jl_hack, or alternatively you can use the
Conda package directly (via `using Conda` followed by `Conda.add` etcetera).

Alternatively, if you want to use a different Python distribution on your
system, such as a system-wide Python (as opposed to the Julia-specific Python),
you can re-configure PyCall with that Python.   As explained in the PyCall
documentation, set ENV["PYTHON"] to the path/name of the python executable
you want to use, run Pkg.build("PyCall"), and re-launch Julia.

) <class 'ImportError'>
ImportError("cannot import name 'factorial' from 'scipy' (/Users/loliansh/.julia/conda/3/lib/python3.7/site-packages/scipy/__init__.py)")
  File "/Users/loliansh/.julia/packages/PyDSTool/T2R3A/src/_pydstool_jl_hack.py", line 29, in <module>
    import PyDSTool
  File "/Users/loliansh/.julia/conda/3/lib/python3.7/site-packages/PyDSTool/__init__.py", line 60, in <module>
    from .Events import *
  File "/Users/loliansh/.julia/conda/3/lib/python3.7/site-packages/PyDSTool/Events.py", line 13, in <module>
    from .Variable import *
  File "/Users/loliansh/.julia/conda/3/lib/python3.7/site-packages/PyDSTool/Variable.py", line 10, in <module>
    from .utils import *
  File "/Users/loliansh/.julia/conda/3/lib/python3.7/site-packages/PyDSTool/utils.py", line 10, in <module>
    from .common import *
  File "/Users/loliansh/.julia/conda/3/lib/python3.7/site-packages/PyDSTool/common.py", line 45, in <module>
    from scipy import factorial

Stacktrace:
 [1] pyimport(::String) at /Users/loliansh/.julia/packages/PyCall/ttONZ/src/PyCall.jl:544
 [2] __init__() at /Users/loliansh/.julia/packages/PyDSTool/T2R3A/src/PyDSTool.jl:24
 [3] _include_from_serialized(::String, ::Array{Any,1}) at ./loading.jl:692
 [4] _require_search_from_serialized(::Base.PkgId, ::String) at ./loading.jl:776
 [5] _require(::Base.PkgId) at ./loading.jl:1001
 [6] require(::Base.PkgId) at ./loading.jl:922
 [7] require(::Module, ::Symbol) at ./loading.jl:917

PyCall points to Python3 in my case too, on OSX.

Do you have any suggestions on how to get it working ?

@ChrisRackauckas
Copy link
Member

I think that we should no longer recommend PyDSTool in the bifurcation section of the docs. If @tkf and @rveltz want to write examples of using the pure Julia bifurcation tools with ODEProblems, I'd prefer to do that since it seems pydstool on the Python side won't be updating any time soon.

@rveltz
Copy link

rveltz commented Oct 30, 2019

Thank you for your suggestion! I still have an issue on my side concerning the wrapper. I wrote a message on slack about it. Once, this is fixed, it is very easy for me to write a tutorial.

As for Bifurcations.jl, it still lacks the computation of Floquet compared to PyDSTool if I am not mistaken. In this case (hope I am wrong), I am not sure we sure whether we should not mention PyDSTool anymore.

@tkf
Copy link
Contributor

tkf commented Oct 30, 2019

As for Bifurcations.jl, it still lacks the computation of Floquet compared to PyDSTool if I am not mistaken.

That's correct (sadly...). Also, IIRC, PyDSTool (or more like AUTO) calculates the Jacobian for the bifurcation analysis/continuation of the limit cycle in a clever way (and uses its intermediate result for Floquet or something like that). What I implemented there was super dumb (just use ForwardDiff).

@rveltz
Copy link

rveltz commented Oct 30, 2019

Yes they use a periodic schur decomposition.

Yesterday, I was trying Bifurcations.jl, there is so much in the test that is not mentioned in the docs, it is a pity. A proper README.md would bring more traffic as well. Considering the amount of work and quality of this package, you should consider adding basic things like Hopf_to_LC... in the docs.

What I implemented there was super dumb (just use ForwardDiff).

Do you mean that you have a way to get the Floquet coeffs? Even if not very accurate, you should add a quick and dirty solution, it can always be improved in the future.

@tkf
Copy link
Contributor

tkf commented Oct 31, 2019

there is so much in the test that is not mentioned in the docs

Yeah, that's true... The reason why I've been shy about this project was that I have hard time understanding some outputs. Maybe there are critical bugs somewhere or I just miss-set some algorithm parameters or my intuition is wrong... (In particular, tkf/Bifurcations.jl#8 was the one behaving strangely. Though I need to clean it up and explain the oddity before asking for a help.)

Maybe I should just document everything and let people find the bugs for me 😛

Do you mean that you have a way to get the Floquet coeffs?

I meant the computation of Jacobian is slow because I just simply hand it over to ForwardDiff.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants