Assign_profiles() has errors

[zeroYXX]

I found two bugs in the GUTILS assign_profile() function. For line 77 in assign_profiles. inflections = np.where(np.diff(delta_depth) != 0)[0] https://github.com/SECOORA/GUTILS/blob/087967888cb037bd7166c51af65b464052aba8b5/gutils/yo.py#L77 This line will think each extreme point is a new profiles. 128 129 130 131 For example, delta_depth = [ .., .., 1.0, 0.0, -1.0, -1.0, …..], then inflections will be [0, 128, 129, 200, ….]. For 128 ~129 is a little profile for extreme point, that will looks like the graph below. 

and I guess the sampling algorithm, between line 57-66 you get sampling data depending on the time interval(tsint), which cases the offset issues in the graph below

I think sampling data can find extreme points, but can’t get a very precisely extreme point.

[zeroYXX]

My example should looks like this, my format looks mess up.

[zeroYXX]

One of my ideas to fix this issue is readjust the profile id by merging the small profile piece and profile offset with previous profile. and I would add code right before assign_profiles return profile_df(https://github.com/SECOORA/GUTILS/blob/087967888cb037bd7166c51af65b464052aba8b5/gutils/yo.py#L123). Base my idea, i make a function to reassign the profile id base on the result i got from Gutils, I ran one test, the result showing In picture below, upper graph is the result without readjust profile id, and second one is the result with readjust profile id.

So I make one function to read following points and return a flag. If there is a real curve(not false curve) coming, It will set flag as "curve coming". and assume every points before that curve was belong to one profile. and this function will be called only when something weird happening, such as straight line has more than one profile or there is a curve exist inside the profile. my idea is something like I make a assumption about slocum glider's direction(go up or down) first, base on direction i assign profile. If the points goes differently than my assumption, I will check the data, if it is ok i leave it alone, if it is wrong, i fix it.

[kwilcox]

@xiangling1994 thanks for the bug report. Would you be willing to throw together a test function that fails with your use case? I'd even take a CSV file that I could load into a DataFrame and pass to assign_profiles.

[zeroYXX]

@kwilcox Hi, you can download data, code and readme from this link: http://cercos.ocean.dal.ca/seafile/f/f6994e0c01/ . If you need anything else, just tell me, very happy to help.

[kwilcox]

@ZEROBRS Sorry for the delay. Looking at this today before making a GUTILS release.

[zeroYXX]

This graph looks really good, can I ask which commit contains the change for this?

On Nov 16, 2018, at 5:29 PM, Kyle Wilcox notifications@github.com wrote:

@ZEROBRS https://github.com/ZEROBRS I've got some changes that seem to be working, this is what your provided ASCII file looks like now after calling assign_profiles:

https://user-images.githubusercontent.com/13939/48648298-d61abc80-e9bc-11e8-8369-b9bf25be6345.png — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SECOORA/GUTILS/issues/6#issuecomment-439534461, or mute the thread https://github.com/notifications/unsubscribe-auth/ALLxNBpoqf5lwmDmeCuo1kcwMmVFNV0xks5uvy5QgaJpZM4SmqIx.

[kwilcox]

I noticed there are still extra profiles being identified at the extremes of the profiles when tsint is set low. I don't think there is a good way around this... the glider bounced a bit at the extremes of each profile. Any ideas? How is this typically handled?

tsint: 4:

tsint: 2:

[kwilcox]

I forgot that was pre-filtering. With the default filters it looks really good:

tsint: 1

[kwilcox]

@ZEROBRS I made a release (3.1.0) that contains this fix. Please let me know if it works for you!