Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"nan" output when simulating "kuramoto_sivashinsky" data in "higher_dim_example.ipynb" #4

Open
DuncDennis opened this issue Sep 21, 2021 · 10 comments
Labels
bug Something isn't working

Comments

@DuncDennis
Copy link
Contributor

When simulating the "kuramoto_sivashinsky" data in the example "higher_dim_example.ipynb", the values in the resulting numpy array sim_data are diverging (nan) for timesteps larger than ~ 620.

image

Contents of environment .yml file in a .txt file, created via conda env export > dunc_env.yml (.yml files are not allowed here):
dunc_env.txt

@baurse baurse added the bug Something isn't working label Sep 21, 2021
@baurse
Copy link
Contributor

baurse commented Sep 21, 2021

Unable to reproduce the bug so far. Please open a python interpreter and post your numpy configuration here, i.e. the output of the following two commands:

import numpy
numpy.show_config()

@DuncDennis
Copy link
Contributor Author

Here the output of :

import numpy
numpy.show_config()

(with activated rc_env environment)
output:

blas_mkl_info:
    libraries = ['mkl_rt']
    library_dirs = ['C:/Users/Dennis/anaconda3/envs/rc_env\\Library\\lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl\\include', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl\\lib', 'C:/Users/Dennis/anaconda3/envs/rc_env\\Library\\include']
blas_opt_info:
    libraries = ['mkl_rt']
    library_dirs = ['C:/Users/Dennis/anaconda3/envs/rc_env\\Library\\lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl\\include', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl\\lib', 'C:/Users/Dennis/anaconda3/envs/rc_env\\Library\\include']
lapack_mkl_info:
    libraries = ['mkl_rt']
    library_dirs = ['C:/Users/Dennis/anaconda3/envs/rc_env\\Library\\lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl\\include', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl\\lib', 'C:/Users/Dennis/anaconda3/envs/rc_env\\Library\\include']
lapack_opt_info:
    libraries = ['mkl_rt']
    library_dirs = ['C:/Users/Dennis/anaconda3/envs/rc_env\\Library\\lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl\\include', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl\\lib', 'C:/Users/Dennis/anaconda3/envs/rc_env\\Library\\include']

@baurse
Copy link
Contributor

baurse commented Sep 21, 2021

The backend seems fine, so that's probably not it.

One possible solution could be that your python uses 32 instead of 64 bit floats for whatever reason. Please post the output of:

import sys
sys.float_info

Besides this, your numpy installation might just be bugged. Please run:

import numpy
numpy.test("full")

and post its output here.

@DuncDennis
Copy link
Contributor Author

DuncDennis commented Sep 22, 2021

The output of:

import sys
sys.float_info

yields:

sys.float_info(max=1.7976931348623157e+308, max_exp=1024, max_10_exp=308, min=2.2250738585072014e-308, min_exp=-1021, min_10_exp=-307, dig=15, mant_dig=53, epsilon=2.220446049250313e-16, radix=2, rounds=1)

The output of:

import numpy
numpy.test("full", verbose = 2)

yields:

image

After installing the package pytest in the rc_env via conda install -c anaconda pytest the numpy test could be performed by running:

import numpy
numpy.test(label='full', verbose=2)

The result of the numpy test was:

image
image
image

Interestingly in the first line of the output it says platform win32 -- Python 3.7.5, pytest-6.1.1, py-1.9.0, pluggy-0.13.1, hinting to a 32 bit platform.


On the other hand, if I run the python code (from https://docs.python.org/3/library/platform.html)

import sys
is_64bits = sys.maxsize > 2**32
print(is_64bits)

it prints True, hinting at a 64 bit environment.


Furthermore the output to conda info also shows a win-64 platform.
image


All the code was run within the active rc_env environment. It seems like numpy "thinks" the platform is 32 bit, eventhough it is 64bit ?

@baurse
Copy link
Contributor

baurse commented Sep 22, 2021

In the last snipped it says the python version is 3.8.8, even though the numpy test uses 3.7.5 as we want it to be? With the conda environment active, please run a simple

python --version

@baurse
Copy link
Contributor

baurse commented Sep 22, 2021

Also please save the first 1000 rows of the sim_data you calculated here:

image
via numpy.save() and send them to me as well.

@DuncDennis
Copy link
Contributor Author

python --version yields the correct version:

image

Apperently the python version stated within the output of the conda info command is referring to the base python version, and thus is independent of the python version in the currently active environment. See: https://stackoverflow.com/questions/56848462/what-is-the-difference-between-the-python-version-stated-in-conda-info-and-that

DuncDennis referenced this issue in DuncDennis/rescomp Sep 22, 2021
…eation

As a temporary fix of the Github Issue #4 regarding the problem generating the kuramoto_sivashinsky data in "higher_dim_example.ipynb", a new environment file was added: "environment_rescomp_np16p6, where the numpy version was downgraded from 1.17 to 1.16.6, since this fixed the bug.
Also 2 test files were added to bin
@baurse
Copy link
Contributor

baurse commented Oct 15, 2021

Playing around with it a bit, the FFT may(?) indeed be the cause of the instability. This would make sense, as it's the only nontrivial operation happening in the entire simulation function.
Also, at least on my machine, using the scipy, instead of the numpy FFT avoided a divergence for all python and scipy versions I tested against. (Although I don't actually now yet if the attractor behavior remains truly unaffected.)

@DuncDennis: Could you checkout the new branch ks_sim_fix and see if the scipy FFT works on your machine as well?
Use the following command:
pytest -v --tb=no --disable-warnings
You'll probably need to install pytest for this, as it's not a requirement for rescomp. The Output should look something like this:
Screen Shot 2021-10-15 at 19 22 28
With the scipy tests highlighted in red.

@DuncDennis
Copy link
Contributor Author

I checked out the branch ks_sim_fix. The two scipy lines in the pytest (which you marked in red) passed on my machine aswell for various scipy versions: scipy = 1.3.2 , 1.4.1 , 1.5.2 and 1.6.2. My numpy version was fixed at 1.17.4.

The pytest result was the same for all tested scipy versions so I only attach one of the outputs.

image

@baurse
Copy link
Contributor

baurse commented Oct 18, 2021

Very nice!
I'll look into the differences between numpy and scipy FFT to figure out where the difference might come from.

In addition, we'll want to implement the Lyapunov calculation algorithm described in the SI of this Pathak paper: "Model-Free Prediction of Large Spatiotemporally Chaotic Systems from Data: A Reservoir Computing Approach"

Once we have that, we can compare Lyapunov Exponents, and if they agree with the literature and the non-diverging numpy simulations, we can just use the seemingly more stable scipy fft instead of the numpy for now.

(We'll still want a very simple KS simulation to compare the scipy results regardless though.)

baurse pushed a commit to baurse/rescomp that referenced this issue Feb 8, 2022
…l_tester

Develop feature statistical tester
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants