OpenDrift / opendrift

Open source framework for ocean trajectory modelling
https://opendrift.github.io
GNU General Public License v2.0
245 stars 120 forks source link

how to make example_long_selafin result active #1117

Open haozi814 opened 1 year ago

haozi814 commented 1 year ago

Hi: There is a issue when I use example_long_selafin.py. The result just like a pic,it cannot be dynamically displayed as in the example and I can't find the problem Do you have any solution to apply? Thanks! 1684410878733

knutfrode commented 1 year ago

There seem to be some problem with your model run, as the particles have not moved. Do you see an error message in the log from the run?

eroome commented 4 months ago

Hi @knutfrode ,

This is the same issue I have encountered. The error is in this line of the reader... File "C:\Users\edroo\opendrift\opendrift\readers\reader_telemac_selafin.py", line 229, in get_variables pm = self.extractslf(frames, duration, self.altitude_ID, idx_3D)[0]


IndexError: index 0 is out of bounds for axis 0 with size 0
knutfrode commented 4 months ago

I believe both the reader and that example script was written by @Boorhin

If you can make it work for you, a pull request is welcome.

jpsiegel commented 3 months ago

Hi, I'm having the same error when running the Telemac3D example, and also when using the reader_telemac_selafin.py for a 2D .slf file. If @eroome or @Boorhin have made any progress on this subject, I could colaborate along to come to a solution. Kind regards.

Boorhin commented 3 months ago

Hi sorry, not had the time to look into the structure of 2D files. Also not had much support for all the improvements I have tried to bring into the project so a bit reluctant to waste more of my time. Obviously 2D structure is different than 3D so the system is looking for the layers that it doesn't find. The reader had previously only be tested with 3D files. I have a problem with merging all the readers together as there is a strong push towards finite volumes grids like if they were the only existing type. Telemac uses finite elements. In my opinion, the best is to add more keywords into the readers to bring proper flexibility (2D,3D, types of elements). But if I do that, I will have to go the same hassle has before with tests not accepting that people work with different software and data architecture than the core team. Without support to get my worked pushed into the project, I cannot help you. I don't have the time to volunteer on this. I can only do as much as my part which is to get the reader to work. Thanks for your understanding.

eroome commented 3 months ago

Hi @jpsiegel,

In the end, I just changed my Telemac model from 2D to 3D to fit the reader. In my case, a 3D model provided further advantages anyway so it made sense to switch.

Ed

knutfrode commented 3 months ago

I do not work with Telamac, so can presently not devote time to this specific development. But I can merge any pull requests with general improvements. But it is then an absolute requirement that all unit-tests must pass, as new features cannot break existing functionality.

jpsiegel commented 3 months ago

Thanks for the replies, I understand the situation, its unlikely to hope for a working 2D Telemac reader at the moment. Our current approach is to interpolate the .slf output file into a NetCDF grid that can be used with the readers.

jpsiegel commented 3 months ago

For anyone in the same situation, we used PyTelTools slf_to_raster.py script to convert a Telemac 2D .slf file to a structured NetCDF that is able to be read with the built in readers.

eroome commented 3 months ago

Hi @jpsiegel,

Thanks, this is useful to know. Using this method does interpolate the unstructured data onto a regular mesh right? Therefore it might not always be suitable.

jpsiegel commented 3 months ago

Yes, precisely.