prcnt_gd seems backward

[lkilcher]

The values of dat.signal.prcnt_gd for RDI ADCPs seems backwards (good values have values of 0, and bad values have values >0).

[lkilcher]

@mcfogarty can you work on this one? I think the process should be: 1) check that all RDI data files have consistent prcnt_gd and bt_prcnt_gd values (i.e., they are all either backwards, or not) ... I just realized that these are called prcnt_gd and bt_perc_gd. We should probably modify these to be more consistent. 2) Check the documentation on what the 'units' of that variable should be (i.e., perhaps they save the data in the file backwards from what it means?) 3) I don't understand what Marjolaine meant in her most recent email:

I also realised your percent good data is absolutely fine. In my case, I need to add one of the three beams to the 4th one.

If it doesn't make sense after looking through the data more, I suggest following up with her about it.

4) I'd recommend making the necessary change in the read_rdi function of dolfyn/io/rdi.py. It will probably be just a few lines near the end of that function, something like:

    if 'prcnt_gd' in dat['signal']:
        # Some comment here explaining why the data is backward.
        dat['signal']['prcnt_gd'] = 100 - dat['signal']['prcnt_gd']

[mcfogarty]

@mcfogartyhttps://github.com/mcfogarty can you work on this one? I think the process should be:

1. check that all RDI data files have consistent prcnt_gd and bt_prcnt_gd values (i.e., they are all either backwards, or not) ... I just realized that these are called prcnt_gd and bt_perc_gd. We should probably modify these to be more consistent. Agree. Update to prcnt_gd and bt_prcnt_gd? I re-read the SMBworkhorse and bottom-mounted workhorse files with dolfyn 0.11.2. Results are consistent. I’ll send you a pdf of a Power Point of the plots separately.

2. Check the documentation on what the 'units' of that variable should be (i.e., perhaps they save the data in the file backwards from what it means?)

See WorkHorse Commands and Output Data Format.pdf Since the coordinate system was 'earth' the percent good fields mean different things (corresponding with field 1,2,3,4). See pg. 150

[cid:image001.png@01D51556.3A758A10]

Field 1 indicates the % of good 3-beam solutions. We want a 4-beam solution, so having 100% in this field is good IF the 4-beam solution isn't available (see Field 4).

Field 2 indicates the % of transformations rejected - the percent of error velocity that was less (Typo? Greater?) than the WE command setting.

Field 3 indicates the % of more than one beam bad in bin.

Field 4 indicates the % of good 4-beam solutions. This represents the BEST data and we want this to be 100%.

1. I don't understand what Marjolaine meant in her most recent email: I also realised your percent good data is absolutely fine. In my case, I need to add one of the three beams to the 4th one. If it doesn't make sense after looking through the data more, I suggest following up with her about it. She might be referring to using both Field 1 and Field 4 from the percent good fields to filter her data?

2. I'd recommend making the necessary change in the read_rdi function of dolfyn/io/rdi.py. It will probably be just a few lines near the end of that function, something like: if 'prcnt_gd' in dat['signal']:

   Some comment here explaining why the data is backward.

   dat['signal']['prcnt_gd'] = 100 - dat['signal']['prcnt_gd’] Not needed, but perhaps a note referring folks to the WorkHorse Commands and Output Data Format.pdf? Only if the instrument coordinate system is set up in BEAM will the percent good actually be the percentage of good pings for each beam. For all other coordinate systems, the field 1-4 descriptions above are in the poorly-named percent good fields.

From: Levi Kilcher notifications@github.com Reply-To: lkilcher/dolfyn reply@reply.github.com Date: Monday, May 27, 2019 at 11:12 AM To: lkilcher/dolfyn dolfyn@noreply.github.com Cc: "Fogarty, Michelle" Michelle.Fogarty@nrel.gov, Mention mention@noreply.github.com Subject: Re: [lkilcher/dolfyn] prcnt_gd seems backward (#57)

@mcfogartyhttps://github.com/mcfogarty can you work on this one? I think the process should be:

1. check that all RDI data files have consistent prcnt_gd and bt_prcnt_gd values (i.e., they are all either backwards, or not) ... I just realized that these are called prcnt_gd and bt_perc_gd. We should probably modify these to be more consistent.
2. Check the documentation on what the 'units' of that variable should be (i.e., perhaps they save the data in the file backwards from what it means?)
3. I don't understand what Marjolaine meant in her most recent email:

I also realised your percent good data is absolutely fine. In my case, I need to add one of the three beams to the 4th one.

If it doesn't make sense after looking through the data more, I suggest following up with her about it.

1. I'd recommend making the necessary change in the read_rdi function of dolfyn/io/rdi.py. It will probably be just a few lines near the end of that function, something like:

5. if 'prcnt_gd' in dat['signal']:

6. Some comment here explaining why the data is backward.

7. dat['signal']['prcnt_gd'] = 100 - dat['signal']['prcnt_gd']

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/lkilcher/dolfyn/issues/57?email_source=notifications&email_token=ALJ5J4CXK4EN3X24YPVHZG3PXQI6TA5CNFSM4HOLIYIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWKHLKQ#issuecomment-496268714, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ALJ5J4GKTWS7B77CUJ2D2IDPXQI6TANCNFSM4HOLIYIA.