Very difficult for users to link eddy attributes to tracks

[pgaube]

Overall I'm very positive about this software packages. I however am finding it nearly impossible to link the tracks to eddy attributes. Since you are intimately familiar with how the code is set up, would it be possible for you to provide a routine that can output track data in the format along the lines of

eddies [struc] eddies.id eddies.lat eddies.lon eddies.date eddies.amp

where each part of the structure array is a [n,1] array where n is the total number of eddies identified in all SSH fields. Therefore the array eddies.id would have the unique ID number of the eddy repeated for each weekly realization of the eddy.

This would be very helpful!

[warmkar]

Hello, I'm going to need just a little bit more clarification on what you are asking for. The format of the current track data is as follows: Column 1 is the latitude of the centroid of the eddy Column 2 is the longitude of the centroid of the eddy Column 3 is the time slice (day) that the eddy is from. To use this data to get the actual day that the eddy is from, use this value as an index to a dates array, and the return value of your dates array will be the day the eddy is from. Column 4 is the index in the struct array of eddies for that particular day. If you get the correct eddies struct that corresponds to the date in column 3, the value in this column is the index in that struct where this actual eddy resides. It is through getting the appropriate struct and accessing the appropriate entry that we relate this track data to actual eddies in the struct.

This being said, are you asking that I provide a routine to replace this track data that we keep with the actual eddy attributes?

Regards, Robert Warmka

On Thu, Dec 4, 2014 at 6:31 AM, pgaube notifications@github.com wrote:

Overall I'm very positive about this software packages. I however am finding it nearly impossible to link the tracks to eddy attributes. Since you are intametly familiar with how the code is set up, would it be possible for you to provide a routine that can output track data in the format along the lines of

eddies [struc] eddies.id eddies.lat eddies.lon eddies.date eddies.amp

where each part of the structure array is a [n,1] array where n is the total number of eddies identified in all SSH fields. Therefore the array eddies.id would have the unique ID number of the eddy repeated for each weekly realization of the eddy.

This would be very helpful!

— Reply to this email directly or view it on GitHub https://github.com/jfaghm/OceanEddies/issues/1.

[pgaube]

Thank you for the response. I was not able to find the information you provided in your response in the comments in tolerance_track_lnn.m. May I suggest that you update the comments at the top of this file to explain what each column and each variable is that is output by the file?

So I had some time this morning and I think I have been abel to figure out how to link everything (my problem was that I hadn't accounted for the fake eddies before). Below is a snippet of code that creates the output in what I find to be a more digestible format (at least this is how I store the data from my tracks). Note that I have made minor modifications to get_eddy_attributes.m (get_eddy_attributes_PG.m).

Maybe this helps clarify what I'm suggesting? Then again, maybe I'm the only one who like the tracks like this.

Thanks!

Pete clear all

%%%% set up paths ssh_path='/Volumes/RAID/ncar_pop/tracking_mat/'; eddies_save_path='/Volumes/RAID/ncar_pop/eddies/'; tracks_save_path='/Volumes/RAID/ncar_pop/tracks/'; fake_eddies='yes'; viewer_data_save_path='//Volumes/RAID/ncar_pop/viewer_save/'; viewer_path='/Volumes/RAID/ncar_pop/viewer/';

% eval(['mkdir ',eddies_save_path]) % eval(['mkdir ',tracks_save_path]) % eval(['mkdir ',viewer_data_save_path]) % eval(['mkdir ',viewer_path])

%% %%Identify and track eddies complete_run(ssh_path, eddies_save_path, tracks_save_path, fake_eddies, viewer_data_save_path, viewer_path)

%% %%procces fake eddies load([ssh_path 'dates']) load([ssh_path 'area_map']) load([tracks_save_path 'anticyclonic_tracks']) load([tracks_save_path 'cyclonic_tracks'])

process_eddies_and_tracks_tolerance('cyclonic',dates,eddies_save_path,cyclonic_tracks,... eddies_save_path,tracks_save_path) process_eddies_and_tracks_tolerance('anticyc',dates,eddies_save_path,anticyclonic_tracks,... eddies_save_path,tracks_save_path)

load([tracks_save_path 'anticyc_tracks_processed']) load([tracks_save_path 'cyclonic_tracks_processed'])

%% %%Get eddy atributes [cc.amp,cc.u,cc.y,cc.x,cc.pxcounts,cc.pixels,cc.area,cc.jd] = get_eddy_attributes_PG( eddies_save_path, 'cyclonic', dates); [ac.amp,ac.u,ac.y,ac.x,ac.pxcounts,ac.pixels,ac.area,ac.jd] = get_eddy_attributes_PG( eddies_save_path, 'anticyc', dates);

%% %%Get liftimes and indexes ant_eddy_counts = zeros(length(ac.y), 1); for i = 1:length(ac.y) ant_eddy_counts(i) = length(ac.y{i}); end

ant_lifetimes = get_eddy_lifetimes(ant_eddy_counts, anticyc_tracks); ant_eddy_track_indexes = get_eddy_track_index(ant_eddy_counts, anticyc_tracks);

cyc_eddy_counts = zeros(length(cc.y), 1); for i = 1:length(cc.y) cyc_eddy_counts(i) = length(cc.y{i}); end

cyc_lifetimes = get_eddy_lifetimes(cyc_eddy_counts, cyclonic_tracks); cyc_eddy_track_indexes = get_eddy_track_index(cyc_eddy_counts, cyclonic_tracks);

%% %%now convert into a format i like

n_edd=sum(ant_eddy_counts)+sum(cyc_eddy_counts); %find max ac id max_acid=0; for m=1:length(ant_eddy_counts) tmp=max(ant_eddy_track_indexes{m}); if tmp>max_acid max_acid=tmp; end end

%prealocate space [eddies.x,eddies.y,eddies.amp,eddies.area,eddies.u,... eddies.area,eddies.Ls,eddies.id,eddies.cyc,eddies.track_jday]=deal(nan(n_edd,1)); st=1; for n=1:length(dates) eddies.x(st:ant_eddy_counts(n)+st-1)=ac.x{n}; eddies.y(st:ant_eddy_counts(n)+st-1)=ac.y{n}; eddies.amp(st:ant_eddy_counts(n)+st-1)=ac.amp{n}; eddies.u(st:ant_eddy_counts(n)+st-1)=ac.u{n}; eddies.area(st:ant_eddy_counts(n)+st-1)=ac.area{n}; eddies.Ls(st:ant_eddy_counts(n)+st-1)=sqrt(ac.area{n}./pi); eddies.cyc(st:ant_eddy_counts(n)+st-1)=1; eddies.track_jday(st:ant_eddy_counts(n)+st-1)=ac.jd{n}; eddies.id(st:ant_eddy_counts(n)+st-1)=ant_eddy_track_indexes{n};

    st=st+ant_eddy_counts(n)+1;

    eddies.x(st:cyc_eddy_counts(n)+st-1)=cc.x{n};
    eddies.y(st:cyc_eddy_counts(n)+st-1)=cc.y{n};
    eddies.amp(st:cyc_eddy_counts(n)+st-1)=cc.amp{n};
    eddies.u(st:cyc_eddy_counts(n)+st-1)=cc.u{n};
    eddies.area(st:cyc_eddy_counts(n)+st-1)=cc.area{n};
    eddies.Ls(st:cyc_eddy_counts(n)+st-1)=sqrt(cc.area{n}./pi);
    eddies.cyc(st:cyc_eddy_counts(n)+st-1)=-1;
    eddies.track_jday(st:cyc_eddy_counts(n)+st-1)=cc.jd{n};
    eddies.id(st:cyc_eddy_counts(n)+st-1)=max_acid+cyc_eddy_track_indexes{n};

    st=st+cyc_eddy_counts(n)+1;

end

ii=find(isnan(eddies.id)); eddies.x(ii)=[]; eddies.y(ii)=[]; eddies.amp(ii)=[]; eddies.u(ii)=[]; eddies.area(ii)=[]; eddies.Ls(ii)=[]; eddies.cyc(ii)=[]; eddies.track_jday(ii)=[]; eddies.id(ii)=[];

save test_eddies eddies

[warmkar]

A function has been created to do this track formatting conversion for you. It uses part of the code you posted to accomplish the proper formatting for the tracks. The file where this function resides is called reformat_track_data_to_chelton.m, and it can be found in the track_lnn/ directory.

This function is now called during a run of complete_run.m, so this new track format will be generated automatically and stored in the directory you provide to hold track data (the directory specified by the parameter "tracks_save_path" in complete_run). This function can also be ran independently of complete_run. The current format is exactly as you specified with your code, where a 1x1 struct holds entries for each of the different entries. Also, I have modified the code you wrote to keep track of the actual date that the eddy was detected instead of the julian date.

Please let me know if you would like any more revisions to this code, or if you would like anything else added or changed in the repository to suit your needs, and I will do my best to accommodate.