On Fri, Sep 29, 2017 at 12:46 PM, Jason Roberts <> wrote:

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

 

Hi Jason,

 

I have the same problem as Vitor. Did you find a solution for this possible bug? Yesterday, the tool was working fine in the morning and I get some outputs with the eddies. However, it never worked again and appears the "error message".

I attached the details in the file "ErrorAttribute_MTM.docx"

 

Thanks in advance,

 

Marta

 

 

On Thu, May 4, 2017 at 11:07 PM, Jason Roberts <> wrote:

Hi Vitor,

 

That may be a bug, or it could be an anomalous result that occurred from your particular set of parameters. Could you please send the complete output of the tool so I can see the parameters that were used? This will help me either repro the bug or figure out why it would have happened.

 

Thanks,

Jason

 

From: [mailto:] On Behalf Of Vitor Galazzo
Sent: Thursday, May 4, 2017 6:58 PM
To:
Subject: [mget-help] Error in Okubo-Weiss eddy indentification

 

Hello,

I am having a problem with the Okubo-Weiss eddy detection. The folowing error is showed:

python.exe: AttributeError: 'NoneType' object has no attribute 'tofile'
RuntimeError: python.exe returned exit code 1, indicating failure.
The following consequences resulted from the original error:
Execution of C:\Python27\ArcGIS10.2\python.exe failed.

I believe that all arguments were inserted corretly because the failure seems be on the Python execution.

Do you have any sugestion?

Thanks.

--

Vitor Galazzo de Paiva

Oceanógrafo - UFPR

Mestrando em Sensoriamento Remoto - INPE

 

--

Vitor Galazzo de Paiva

Oceanographer - UFPR
Ongoing MSc. in Remote Sensing - INPE

To unsubscribe from this list, visit: https://lists.nicholas.duke.edu/sympa/ca/initiate_unsubscribe/mget-help/martatobena%40gmail.com

 

--

Marta Tobeña

PhD student

MARE – Marine and Environmental Sciences Centre

University of the Azores

Portugal