plotting issues in Ch4 and Ch2/3

Hi,
After I ran my Fortran code and saved the result to a txt, it gave an error when feeding into the python script:

plot_water_height.py:26: VisibleDeprecationWarning: Creating an ndarray from ragged nested sequences (which is a list-or-tuple of lists-or-tuples-or ndarrays with different lengths or shapes) is deprecated. If you meant to do this, you must specify 'dtype=object' when creating the ndarray
h = np.array([[float(x) for x in line[1:]] for line in data])
Traceback (most recent call last):
File "plot_water_height.py", line 27, in
x = np.arange(1, h.shape[1]+1)
IndexError: tuple index out of range

I am not sure how to fix the python script. Thanks.

[milancurcic]

Hi @DEKOHG, thanks a lot for reporting! This sounds similar to #10. Can you look there and see if perhaps the same thing is happened to you as well?

If not, I'll try to reproduce. Can you let me know your Python version, as well as attach the output file from tsunami that you're passing to the Python script?

Hi,
Thank you for your prompt reply!
I have looked into more with my code and the code on this repo and the PR you mentioned.
I think the problem arises from the compiler's printing format. In the following, I will mainly talked about the Ch4 code.

I an working on a Windows operating system so that I used Intel's Fortran compiler from their oneAPI.
With such setup, the out put txt from the Fortran code will be as the attached tsunami_output.txt format (from Intel compiler).
However, if I use gfortran to compile according to your Makefile, the output txt will be as attached tsunami.txt (from gfortran). With this format, the python script runs without error, though I can only see a water_height_5000.svg as a static image without animation.

I am using python Python 3.8.8 [MSC v.1916 64 bit (AMD64)] :: Anaconda, Inc. on win32
with numpy version: 1.19.2, matplotlib: 3.4.1
tsunami_output.txt
tsunami.txt

[jpc2]

I'm seeing the same problem using a fresh install of ifort and IPython. It has been too long since I did much with python.
The first problem - M$ seems to have changed from UTF-16 to UTF-8 at some point. So the error I was getting trying to read the tsunami.txt file. Changing unicodeVar from 'utf-16' to 'utf-8' solved that.
The second is the VisibleDeprecationWarning problem. The cause is that for some reason ifort is breaking the 'print *, n, h' output into multiple lines that appear to be less than 80 characters. (You'd almost suspect that it thinks it is talking to a Card Punch!). Have not had a chance to dig into it yet.

[milancurcic]

Hi @jpc2 @DEKOHG, does this issue persist as of #15? That PR replaced the list-directed format (*) with an explicit format that is consistent between compilers.

[jpc2]

Well, maybe not cards, but they do insert \n in the output at about 80 characters to make it 'human readable'. The fix is to supply the compile flag --no-wrap-margin in Linux and /wrap-margin- in Windows (note the trailing '-').

Hi @milancurcic,
The change to using the fmt statement seems to work fine without the '/wrap-margin-' flag.
You might want to remove the unicodeVar setting and use in plot_height_multipanel.py. Windows seems to be getting on the UTF-8 wagon.

[milancurcic]

Thanks @jpc2, the UTF-16 setting was introduced in #13 specifically for compatibility with Windows. I really don't know Windows and don't know better one way or another, but happy to revert if that change was actually adverse.

Is there any official Windows doc specifying which Unicode formats are supported by which OS versions?

[jpc2]

@milancurcic if there is an official Windows doc that gives real specifics I've not found it. The closest I've found is https://docs.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page.
I like the book. I've been around FORTRAN since '65 or so. Alway doing maintenance, seldom anything new, and always with compilers that were old and barely supported. So it is interesting to see what new stuff looks like. I mentioned punch cards because the first paying programming I did was radar data on an IBM 709.