[ferret_users] curl error when accessing a THREDDS

[Martin Schmidt <martin.schmidt@xxxxxxxxxxxxxxxxx>]

Hi,

I am not really sure where to send this question to. From time to time I 
get the following error when reading data from a THREDDS server:

CURL Error: Failure when receiving data from the peer

but ferret continues ...
 LISTing to file  ....

Anyway, if this happens, the resulting data are shifted within the grid 
and the result is useless.
It is hopeless to find the "rule" how data are changed.

Ferret is calculating a climatology from a huge model output. That 
requires to split the model domain into subdomains.
After defining a region, the results for the climatology are written 
into separate files and joined later. The scripts for
finding the climatology are simple, just like in the tutorial. The data 
flow is

use "http:......"
set region
find the climatology
save to file
set region
find the climatology
save to file
and so on

The error shows up only intermittently. I have checked that the data set 
on the THREDDS is sane.
The THREDDS is pretty old, Version 4.2.10 - 20120417.2151. The access 
log of the THREDDS looks as it should. I discovered from the logs, that 
some of my tiles should be smaller, since ferret sends two requests to 
the THREDDS subdividing also the vertical coordinate. This works mostly 
well, but it seems, that the error shows up only in this case.
As a test - with smaller tiles I did not see the error yet but the 
calculation takes much longer.

Ferret is pyferret 6.96 (PyFerret 1.2) running on OpenSuse 13.2. It is 
py_ferret_120_ub_py_27.
The same for ferret/6.951. This was a prerelease of 6.96 (not pyferret!)
With older ferret/6.85 some files are written. Later a similar error 
shows up but I get more details and ferret stops:
curl error details:
 **netCDF error
             NetCDF: I/O failure (OPeNDAP/netCDF Error code -68)
             Data set: 
http://phy-4:8080/thredds/dodsC/genus/genus_era_exp13_run_40_5day_ocean.nc
This is a "Generic IO error". What does this mean?

I have no idea, how to fix this. Did anybody observe something similar?

Best,
Martin Schmidt