Hi Marta,

Thank you for the error details. I believe I can guess the problem. The start date and end date listed in the output were 01/01/2001 and 03/01/2001. In the past, I determined that ArcGIS provides dates to Python tools in whatever format is utilized by the operating system. MGET is programmed to ask Python for that format and then try to parse the dates using it. In your operating system, those dates appear to mean 1 January 2001 and 3 January 3001. So the tool believes it has been asked to produce eddies for a 3 day period at the beginning of 2001.

I’m pretty sure what happened is that the tool then ran but detected no eddies. Then, when it attempted to create outputs, it failed because I never anticipated that this situation of no eddies would ever occur. So I should fix that and have it succeed and return a sensible message.

But the real question you want to know is: why did it detect zero eddies? The problem is that the tool has a parameter called Minimum Duration of Eddy Cores, under the Okubo-Weiss Algorithm Parameters. This is set to 28 days by default. So, by default, an eddy must persist for 28 days in order for the tool to retain it. Otherwise the tool will discard it as being too ephemeral to be counted as an eddy. If I recall correctly, the default of 28 days comes from the Chelton et al. (2007) global eddy census—they used 4 weeks as the minimum lifetime for an eddy.

So to fix this problem, you should either increase the end time to be at least 28 days long, or decrease the Minimum Duration of Eddy Cores. Perhaps you could try setting the end date to 31/01/2001 and try again? It appears that your connectivity to the AVISO servers are good enough that it would require less than one minute to download the data.

I should mention that the tool is currently programmed to download data from AVISO’s OPeNDAP servers. AVISO has shifted public release of their data to the CMEMS system. AVISO will probably shut down their OPeNDAP server at some point. I have been extremely busy this summer and not been able to change this part of MGET to use the CMEMS system instead (it uses FTP instead of OPeNDAP, making the change complicated). So it looks like you are ok for now, but out for that problem in the future. Apologies for not having fixed it yet. Hopefully I will have time in the autumn.

Hopefully this answer’s Vitor’s question as well. I inquired further with him at the time but did not see a response from him (apologies to him if I somehow missed it!)

Best,

Jason

From: Marta Tobeña [mailto:]
Sent: Friday, September 29, 2017 5:41 AM
To: Jason Roberts <>
Cc: Vitor Galazzo <>;
Subject: Re: [mget-help] Error in Okubo-Weiss eddy indentification