Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rotational speed #14

Open
claudiofgcardoso opened this issue Aug 20, 2017 · 3 comments
Open

Rotational speed #14

claudiofgcardoso opened this issue Aug 20, 2017 · 3 comments

Comments

@claudiofgcardoso
Copy link

claudiofgcardoso commented Aug 20, 2017

Hello,

First of all, thank you for making this tool freely available. I'm using MatLab's version to track and characterize the eddy field around Cape Verde. Everything worked fine! However, I'm getting seemingly incorrect geographical patterns for the rotational speed.

eddies_inside_rot_speed_30days_v2

I posted a similar result in a comment related with the same issue. What bothers me the most is the close to zero speed values... Is this problem related with the "tolerance_track_lnn" or the "process_eddies_and_tracks_tolerance"? Or am I doing something wrong?

Greetings,
Cláudio Cardoso

@lematt1991
Copy link
Collaborator

Which detection (v1, v2, or hybrid) and tracking (lnn or mha) algorithms are you using? You might try comparing a few other approaches. I'll defer to @jfaghm for an official response though.

@claudiofgcardoso
Copy link
Author

I used the already processed eddy features (Global mesoscale ocean eddy features) available at http://datadryad.org/resource/doi:10.5061/dryad.gp40h. For the tracking, I used the lnn algorithims with a 3-day tolerance.

Is it possible that the problem is related with this dataset?

@claudiofgcardoso
Copy link
Author

Hello again,

@ml9951 Following your suggestion, I scanned the original AVISO SLA dataset for eddies using both v1 and v2 detection methods. Unfortunately there is no improvement in the final results...

image

This image was created by computing the mean geostrophic speed within the daily .mat files generated with the function "scan_multi.m". So, the problem must be in the calculation of the mean geostrophic speed and not in the tracking (lnn or mha) algorithims.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants