Closed 5hwetabh closed 5 months ago
Hi, thanks for reporting this. Can you share the output of tdgl.version_dict()
?
A fresh install on Google Colab executes the entire quickstart.ipynb notebook successfully:
This is the output on my .conda env:
{'tdgl': '0.8.2',
'Numpy': '1.26.4',
'SciPy': '1.10.1',
'matplotlib': '3.9.0',
'cupy': 'None',
'numba': '0.60.0',
'IPython': '8.25.0',
'Python': '3.11.9 | packaged by Anaconda, Inc. | (main, Apr 19 2024, 16:40:41) [MSC v.1916 64 bit (AMD64)]',
'OS': 'nt [win32]',
'Number of CPUs': 'Physical: 8, Logical: 16',
'BLAS Info': 'Generic'}
And the output on my .venv:
{'tdgl': '0.8.2',
'Numpy': '1.25.2',
'SciPy': '1.10.1',
'matplotlib': '3.7.1',
'cupy': 'None',
'numba': '0.58.1',
'IPython': '8.25.0',
'Python': '3.11.9 (tags/v3.11.9:de54cf5, Apr 2 2024, 10:12:12) [MSC v.1938 64 bit (AMD64)]',
'OS': 'nt [win32]',
'Number of CPUs': 'Physical: 8, Logical: 16',
'BLAS Info': 'OPENBLAS'}
The same traceback occurs in both.
I think I found the source of the traceback in solution/solution.py: if len(Solution.dynamics.times)%step == 1 (as on my laptop) the resulting Solution.times array is one shorter than it would otherwise be, which might be what causes this traceback.
Does't line 148 in that screenshot handle the case len(solution.dynamics.times)%step == 1
?
Can you print out solution.dynamics.time[-3:]
and solution.times[-3:]
?
Actually can you just upload the HDF5 file here so I can take a closer look? Thanks
It seems GitHub doesn't allow the large file, so I shared it via DropBox instead. I have never used h5py before so I hope it is the correct file.
I am under the impression lines 145-146 handle cases where len(Solution.dynamics.times)%step == 1
and line 148 handles it when false (i.e. 99% of the time); I apologize if I am incorrect.
Thanks for helping me with this issue!
Thanks. I think the issue is that if the total number of solve steps ends up being a multiple of options.save_every
, the data for the final time step is saved twice. The data for solve step 30700 is saved in both data[307]
and data[308]
in the HDF5 file (see below). It is very rare that a simulation with an adaptive time step will end on a step that is a multiple of options.save_every
, which I think is why I have never seen this problem before.
I opened a Pull Request that I think will fix the issue: https://github.com/loganbvh/py-tdgl/pull/83. I will merge the Pull Request and release a new version on PyPI either later today or tomorrow. It is a one line fix: https://github.com/loganbvh/py-tdgl/pull/83/commits/1cbeefb2ea200a9294095ea3a91c1e0523a560c4
Thanks a ton for the prompt fix! I am happy to say that I have learned a lot of Python from this issue.
Edit: I can confirm I no longer get a traceback after manually applying the fix.
Firstly, thanks for creating this incredibly helpful package!
I have tried running the 'quickstart.ipynb' notebook as-is (except setting
MAKE_ANIMATIONS = 0
), but I keep running into the same traceback across both my Windows laptops and various versions of python: On code cell 21, the linefluxoid = zero_current_solution.polygon_fluxoid(polygon, with_units=False)
results in an index error:I am not able to find the source of the issue directly, but I did check some relevant values which hopefully will help:
len(zero_current_solution.dynamics.time)
returns 30701len(zero_current_solution.times)
returns 308len(h5py.File(zero_current_solution.path, 'r')["data"])
returns 309