I am testing the CV model for an exposed coast in the Mediterranean and my first run was completed, however I got this warning for every shore_id point: found fetch ray at shore_id … with no bathymetry data, assuming depth of -1 for wave height & period calculations
The same messages were also in the log for another run where I selected a lower maximum fetch value so the fetch rays would not exceed the limits of the provided bathymetry file.
In the intermediate results file “fetch_points” it seems that the vast majority of the “fdepth” columns for all directions are NULL. In this post Pardon my fetch - Fetch rays with no bathymetry data - #2 by dave however it is mentioned that Many will beNULLfor the fetch rays that point towards land. The “fdist” columns have some 9999,999 values, which possibly has to do with the link above and may be irrelevant with the problem reported here.
I would appreciate some guidance on how to manage this issue as well as how this warning affects the model results (since the model run completes despite the warning). Also, any comment on the maximum fetch value selection, if relevant.
Hi @byron , good idea to check the intermediate results. If you see fdepth_XX values that are NULL where the corresponding fdist_XX is 0, that is to be expected. In that XX direction, there is no fetch ray because it is a landward direction.
The maximum fdist value you should see is whatever value you specified for the “max fetch distance”. If you see values exceeding that, something likely went wrong.
If you would like to package up your output workspace I can take a closer look. Also, please always attach your logfile here. Thank you,
The maximum fdist values are indeed up to the the max fetch distance in my last model run (though in a former run actually there were 9999,999 values, maybe it had to do with something else…).
The problem is the NULL for fdepth, as they do not correespond with fdist=0 but with -literally- every point and direction regardless of the fdist.
Hi @byron , thanks for sharing your data. I think I’ve found the problem. The model is incorrectly handling nan values in the bathymetry raster. nan seems to be the nodata value of your bathymetry layer, and the model is trying to average it into other real bathymetry values, resulting in all those NULL values.
The good news is, I believe this problem is already fixed in the latest version of invest (3.14.1 as I write this). Could you please try that version and see if it yields correct fdepth values?
Also, you may wish to adjust your max_fetch_distance parameter, or the coverage of your landmass polygon and bathymetry. As-is, the fetch rays extend far beyond the coverage of the landmass and bathymetry. The model should take this fetch distance into account before clipping the landmass or bathymetry, so I assume your input datasets look similar to this picture?
If there are other landmasses to the north/south, then excluding them would create artificially long fetch rays in those directions, which influence the wind and wave exposure calculations.
For the bathymetry, missing data along the rays will influence the wave height & period calculations, which influence wave exposure. It’s okay to have some missing values under the fetch rays – version 3.14.1 will ignore them – but if you really do believe that wind-driven waves can propagate over those distances, then you probably want reasonably accurate measurements of the ocean depth along the whole distance.
Thank you for the answer. I understand and agree that the input files for landmasses and bathymerty should be much broader than the AOI, for obtaining realistic results for every specific setting (I used that setup to get familiar with the model). However, in my view this is kind of irrelevant with the successful model completion, if the maxfetch distance is set as low as needed for the longer rays do not exceed the other input files’ coverage.
That’s why I had tried some model runs with this condition fulfilled, as I mentioned in my initial message:
which also concerns the first solution you proposed.
So, even the snapshot you sent is simIlar indeed for that input, even for other maxfetches the warning was there.
I tried that with further lower value (unreal) and also under 3.14.1 version, but the warning continues.
Anyways, the problem can be considered solved: I downloaded bathymetry (GEBCO) for a broader area and run the 3.14.1 version and the warning was gone. I also excecuted some test runs with a larger AOI and with higher maxfetch value, all good.
I think under this version some missing values along few rays are actually ignored, as you mentioned.
To sum up, it seems that the bathymetry file has to be large enough, the landmasses not that crucial for warnings. My dought is if the problem was relevant with my initial bathymetry file, which had higher resolution (also data type float32 while GEBCO is Int16, if related), as my intention is to use high resolution if available. Selecting a max fetch value that should be more appropriate for the model in cases of coasts exposed to open sea (no obstacle for several hundreds of km) is also still kind of questionable.
I would appreciate any suggestion on the above, as they any future model run depends on them.
Thank you for your time,
All the best
P.S. The development build you sent me was not excecuted as antivirus identified possible infection, probably it will not be necessary though.
My comments about the spatial extent of the bathymetry and landmass relative to the max fetch distance were just general suggestions, not directly related to solving the problem of the warnings about NULL depth values.
As I mentioned earlier, the original problem was created by the presence of nan as the nodata value in your bathymetry raster. Presumably the GEBCO dataset does not use nan and thus the problem was avoided. If you wish to use your original bathymetry layer with invest 3.14.0 or 3.14.1, you will need to reclassify the nan values to any other number and make sure to assign that new number as the nodata value. And a future version of invest will treat nan properly.
Yes I undesrtand, our conversation was very helpful anyways. Besides, after that I interpreted fully the nan issue… I thought the problem was the nan values which are result of missing values outside the bathymetry extent for longer rays, but nan values may exist throughout the area the bathymetry file includes.
Thanks again,
all the best.
