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

Update plot_water_height.py #10

Closed

Conversation

NuclearEngideer
Copy link

Fixes deprecation warning for creating an ndarray from ragged nested sequences
Fixes index out of range for h.shape tuple

Python 3.8.2 on macOS 10.15.7.

Appears to generate expected results when compared to the plotter from the chapter 4 code.

Fixes deprecation warning for creating an ndarray from ragged nested sequences
Fixes index out of range for h.shape tuple
@milancurcic
Copy link
Member

Thanks for the PR. Hmm, this breaks it for me with matplotlib==3.3.4 and numpy==1.19.5 on Python 3.6.8.

Traceback (most recent call last):
  File "plot_water_height.py", line 37, in <module>
    plt.fill_between(x, -0.5, h[time_step], color='b', alpha=0.4)
  File "/home/milan/Work/modern-fortran/tsunami_NuclearEngideer/venv/lib/python3.6/site-packages/matplotlib/pyplot.py", line 2640, in fill_between
    **({"data": data} if data is not None else {}), **kwargs)
  File "/home/milan/Work/modern-fortran/tsunami_NuclearEngideer/venv/lib/python3.6/site-packages/matplotlib/__init__.py", line 1447, in inner
    return func(ax, *map(sanitize_sequence, args), **kwargs)
  File "/home/milan/Work/modern-fortran/tsunami_NuclearEngideer/venv/lib/python3.6/site-packages/matplotlib/axes/_axes.py", line 5303, in fill_between
    where=where, interpolate=interpolate, step=step, **kwargs)
  File "/home/milan/Work/modern-fortran/tsunami_NuclearEngideer/venv/lib/python3.6/site-packages/matplotlib/axes/_axes.py", line 5207, in _fill_between_x_or_y
    getattr(self, f"convert_{dep_dir}units")(dep2))
  File "/home/milan/Work/modern-fortran/tsunami_NuclearEngideer/venv/lib/python3.6/site-packages/numpy/ma/core.py", line 2371, in masked_invalid
    condition = ~(np.isfinite(a))
TypeError: ufunc 'isfinite' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''

It looks like when the the np.array is created this way that it's not supported as input to np.isfinite(). Do you know why it works on your end?

@NuclearEngideer
Copy link
Author

@milancurcic

Interesting! I don't know what the difference is..

I am using Python 3.9.5, numpy 1.20.3, and matplotlib 3.4.2.

I am wondering if somehow the data file my parallel 1D tsunami sim generates is different from the script's expected input structure.

In the patch I suggested, h.shape returns (5005, ) even though I am running 5000 time steps. The plotter also fails on my end for time step arguments < 10 (but you can still generate a neat gif).

I just went ahead and ran the chapter 7 tsunami sim from this repo and h.shape returns (5001, 100) which is definitely what I would have expected. There was also no deprecation warning here. Somewhere, something has gone wrong with my sim, so I think I've opened this PR prematurely.

With data generated from this repo's executable, there is no deprecation warning during the script execution.

And because this is now a running stream of consciousness debug log, I left a print *, 0, h in place just before time_loop so each image wrote this to my output file which has messed up the size. Adding the proper gather and sync conditions prior to the print statement

Reverting the python script to normal but forgetting to remove the dtype=object statement threw the error above. Removing that lets the script work again.

I'm closing this pull request because I am a fool. Great learning experience though!

@NuclearEngideer
Copy link
Author

I think the deprecation warning about ragged lists is because my sim had the first print statement executed by each image prior to entering the loop which made the first entry in the output file a different length than the rest and therefore screwed everything up.

@milancurcic
Copy link
Member

@NuclearEngideer thanks, that's funny and I'm happy you could trace it back. Please let me know if you spot anything else, I bet there are a ton of little issues like this. And thank you for reading!

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

Successfully merging this pull request may close these issues.

None yet

2 participants