-
Notifications
You must be signed in to change notification settings - Fork 72
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
Add beam dimension to Beam group #520
Comments
Note about a related change in the draft SONAR-netCDF4 version 2: Under 7.1. Significant changes from version 1 to version 2: Beam: Added variables for the description and storage of data from split-aperture beams via a |
One thing I haven't looked into is what value the single-element (length 1) |
Here is the definition of the beam coordinate in the convention, including its data type:
|
To tackle the first item in this issue, we need to address a few items:
|
Ah. I think it should be changed to string type, so that a string type
It just occurred to me to look this up in the convention. It's not a perfect guide, because the dimensionality of And finally, just a reminder that |
In the EK80 case I think it would still be 0, 1, 2, 3 (or 1, 2, 3, 4) since here we are setting each quadrant (or sector) of a transducer to a "beam" -- note that how people define a beam can vary depending on the context -- whether or not it corresponds to an actual physical elements, or is it a beamformed results, etc. A potential problem is that when setting the beam to strictly of string type is that users can get confused trying to index using integer instead of string (i.e.,
I think it is also the most convenient during computation, since many of the operations would end up doing something like |
@leewujung and @emiliom thank you for your input. Here is my summary so far:
Items that still need to be addressed:
|
I am currently reviewing an EK80 sensor with the current dev version and I see for this sensor we added the data variables:
|
Regarding the data type for Regarding frequency, serial_number, sonar_model, sonar_serial_number, sonar_software_name, sonar_software_version in the |
Actually, since a string type |
It makes sense to use a string type for the
Since there seems to be items beyond the addition of the I found that for EK80 there is no |
For beam name or beam ID, I don't think there's that in EK80 files.
For Beam_group2 because it is power/angle format, data from the "beams" are processed to extract the angle data, so there is no "beam" per se. BUT, to make it consistent, I think we will be adding a
I agree with creating another issue for this -- I haven't had a chance to think through and dig through what the variations may be across different sonar models but it'll be nice to have a focused discussion there. |
Since there is no name or beam ID for EK80 and this seems to not exist for EK60 too, it looks like we are left with using numbers. If this is correct, I suggest that for 4 beams we let |
I agree with what's been stated in the preceding comments. The only tweak I'd make is to use base 1 for the string label. So, for the length-1
Indeed, @b-reyes and I met yesterday and realized that the EK80
👍 |
I agree with @emiliom's comment above! |
@emiliom and @leewujung thank you! It looks like we have arrived at a consensus. Just to summarize the changes that will take place:
|
The following is a discussion on what variables should have the beam dimension (for EK60). Whether or not to include the beam dimension was initially based on the 1.0 convention. Based on EK60
@leewujung has made the following comment on the variables beam_direction_x/y/z, angle_offset_alongship/athwartship, and angle_sensitivity_alongship/athwartship for EK80. This is regarding the addition of the beam dimension to the variables. "there is only 1 transducer and 4 "beams" included in EK80. If we were to add the beam dimension, maybe duplicate all values for all 4 beams" Currently, in the convention "These variables are frequency dependent so the frequency (renamed to channel) dimension has to be retained. For EK60 this does not change across ping_time. If convention requires ping_time the value should be duplicated." |
Thanks @b-reyes. For beam_direction_x/y/z, angle_offset_alongship/athwartship, and angle_sensitivity_alongship/athwartship: I think more context should be added here for making a decision. The 4 "beams" stored in EK80 are different elements of a split-beam transducer. The number of elements could also be 3. I think adding a length=1 Many of the same split-beam transducers can be used interchangeably between EK60 and EK80. The reason why you don't see data from these 4 elements is because EK60 does this processing and store only the split-beam angle (along with power) in the data. In other words, users do not have access to the "raw" complex data in EK60, but they do for EK80. Users can select whether they want EK80 to store the "raw" complex data or the "processed" power/angle data in a form comparable to EK60, separately for each channel. That is why you can have co-existing complex and power/angle data in a single EK80 file. |
@b-reyes : based on our discussions, below is what I think at the moment for the dimensions. Let me know if some of these do not work with your understanding of the convention. Here we are taking an approach of "addition" to only add dimensions to the variables if they do not already exist, but we DO NOT remove any dimensions from the convention. So, in practice, this means that we have a lot of identical values along the dimensions that are defined in the convention but are single values from the data file. As @b-reyes suggested, let's take EK60 first: EK60:
Update 2022/04/14 8:39 PM: I realized I made a mistake for the last bullet point. For these echopype-added variables, let's NOT add the beam dimension as @b-reyes suggested. |
@leewujung thank you for putting that list together. Here are also some other notes for EK60 (some items have a strikethrough them, please ignore them and see my comment below)
|
Thanks @leewujung and @b-reyes for compiling these! @b-reyes , one general comment: You list a few variables that don't have a So, all such cases can be treated as following the convention, so to speak. |
@emiliom thank you for pointing that out. I thought that might be the case, but I wanted to make sure. Taking this into account, does the following look more correct for EK60?
|
As you listed earlier, for
Correct |
@leewujung and @emiliom I am slightly confused here. Are we going with option 1 and 2? For EK60 we have the following values: |
re: 1-way vs 2-way beamwidth: So, per TODO in the code, it looks like the 2-way beamwidths from the raw datagrams ( But we're diverging from the core of this issue. Same goes for the decision about athwartship/alongship vs major/minor. A new issue should be opened, IMHO |
Replies to some of the comments/questions above:
Not really - the athwartship/alongship became common because ships were the main use of Simrad gear for many years. The use of sounders on other platforms is where the use of major/minor came in as a more general nomenclature. For mooring deployments, the tack is to define the direction of the mooring minor/major axis and then apply a platform heading to get true pointing direction (just as for a vessel).
Indeed, yes! I didn't think that one through fully. |
@emiliom I agree with your statement, this seems like it should be moved to a different issue. Is this topic something that needs to be completed before v0.6.0 can be released? |
re: 1-way vs 2-way beamwidth:
@b-reyes : yes let's get it in for v0.6.0. I can do this one (i.e. please assign it me!) once we have the beam dimension and the |
To bring the conversation back to the core discussion, there are two items we need a decision on for EK60.
To adhere to the convention, I suggest that we let
As these variables are not in the convention, we get decision making power here. @emiliom what do you think? |
I agree. Sigh.
I agree with assigning them (And just to elaborate on their similarity to related variables that are either in the convention or have analogs in the convention: those variables were missing |
Summary of dimension decisions for EK60. As @leewujung stated, “Here we are taking an approach of "addition" to only add dimensions to the variables if they do not already exist, but we DO NOT remove any dimensions from the convention. So, in practice, this means that we have a lot of identical values along the dimensions that are defined in the convention but are single values from the data file.” EK60:
|
Now that we have decided what the dimensions for EK60 will be, let’s continue our discussion with EK80. Most variables are similar to EK60 with some minor additions, but I have included all of them for future reference. EK80:
|
Thanks for the summary @b-reyes, this is a huge job! For EK80, everything you listed looks fine. My comments on the questions are below:
Yes please add them. Agreed on adding the
This is the same issue as the
Slope can change ping by ping and be different for each
This does not change ping by ping in a single file, so I suggest saving it with dim: There is in theory a possibility that someone decided to change the transceiver software in the middle a survey and later want to do |
@leewujung I am currently writing up an issue for this, however, I wanted to clarify something. Based on the conversation with @gavinmacaulay, it seems like we should not "... use the same numbers in As this will be handled in a separate issue, should we leave these varaiables' dimensions unchanged for now?
Great, I will leave this variable unchanged.
Sounds good, I will leave this variable unchanged also. |
What I meant was that I will take care of the value mismatch in my later PR after your PR. Don't want you to worry about that right now (we'll circle back to the physics once we're done with this push). But please encode the variables with the correct dimensions in what we have discussed above, so that I don't end up making mistakes in my PR. |
For EK60:
This variable was incorrectly found in the For EK80:
@leewujung wouldn't this variable be better placed in the BTW, I just noticed that in the sample EK80 raw data file I've been using ( |
I agree with the above. |
We have arrived at a consensus for EK80! Summary of dimension decisions for EK80. EK80:
|
Note that we will not be addressing the AD2CP sensor in this issue, this will be left for a future version of echopype. Thus, the last items to discuss are the AZFP sensor dimensions. AZFP:
|
The dimensions for AZFP listed above all look good. I just have some comments below on where specific form of data come from, and placement of specific variables.
In the same data file AZFP does not have the flexibility like EK systems to change
I have some suggestions where the variables should be moved to. I was definitely not thinking about the variable placement earlier.
|
Based on our Thursday meeting, we have come to a consensus on the variable dimensions of the beam group for AZFP. To summarize, here are the final decisions on the dimensions for AZFP: AZFP:
|
We are ready to close this now. 🎉 |
(Updated 2022-3-30). Add a
beam
dimension toBeam_groupX
groups. We've decided to always include thebeam
dimension, instead of relying on an implicit length-1 dimension.beam
dimension is not used explicitly and is effectively length 1. We'll need to add it.quadrant
dimemsions and coordinates tobeam
#619 For EK80 there is already a dimension calledquadrant
that is conceptually equivalent (for our purposes) to thebeam
dimension as defined in SONAR-netCDF4 v1. We will need to rename it tobeam
.Older notes (just for reference):
beam
)quadrant
(WJ: there is an extra dimension quadrant — you can call them separate beams, but since Simrad use quadrant i used that for our first shot though I think it should be probably sector since it is not always 4)beam
dimension. Single-value dimensions can be implemented interchangeably in a netcdf file either explicitly with the dimension or implicitly (refer to the CF convention). In SONAR-netCDF4, since there is an explicitbeam
dimension, single-beam data would be expected to be stored withbeam
as a dimension.beam
dimension (ie, >1 beams per Beam subgroup? Based on "beam mode" alone?)The text was updated successfully, but these errors were encountered: