Duplicate WMO assignments.

[tlmaurer]

Hello,
Within the GO-BGC program, we have recently been encountering cases of duplicate WMO assignments. Some of these issues can be traced back to duplicate assignments in original distributions from OceanOps (that later got reconciled in one place, but took longer to resolve in all places of the system).

1. We are curious if other DACs have run into this (if so, can you list the WMO?) or if it is primarily an issue with how the WMO are being assigned in larger batches for bigger programs. ?
2. If OceanOps has insight into this issue (and/or how we can help to prevent in the future) - that would be great to hear.
   Here are WMO for three recent discrepancies:
   3902557
   2903865
   4903745
   Thanks!

[JohnEGilson]

SIO has had 3 WMO that were assigned to us via NOAA a couple years ago, that I finally got around to using to find out they had been in the interim given to other groups. The WMOs were 5906966-68. The situation has been rectified at the GDAC.

[vturpin]

A bit of background:

Before the implementation of the API to request WMO IDs, the allocation of WMO ID batches was done manually by a few WMO officers, and these batches were stored in Excel files. This manual process led to duplication issues (like the one described by John). As a result, WMO asked us to establish a more robust system for managing all WMO IDs for ocean platforms (including met/ocean).

This system was implemented in 2023, if I recall correctly, through an API service or an online "request ID tool."

To prevent duplicates, we made an effort to collect all the batches previously issued by WMO officers and remove them from the "random" allocation tools. We did our best to gather the most comprehensive list of already allocated WMO IDs, but we cannot entirely rule out the possibility that some past allocations may not have been identified by the new allocation tool. These cases should be minimal.

Additionally, despite our efforts to prevent such issues, we cannot completely exclude the possibility that the OceanOPS migration may have disrupted the flow of WMO ID allocation.

Consequently, we need to understand better the current issues and make sure the way we request WMO ID today is as robust as expected and limit this cases in the future.

[OrensOceanOPS]

also 2903863 ?

[vturpin]

Hi,

We will investigate this situation here.with the following list of WMO and try to find out why you faced dupicates for those.
2903863
2903865
3902557
4903745
5906966
5906967
5906968

In the meantime, I would suggest to request WMO ID only from the OceanOPS API (Request ID) and get rid of WMO ID assigned before the set up of this tool in 2023 (if I recall well).

[fionacarse]

Hi Tanya,

[minor comment from UK that is probably already covered by what's been said by others!]

We've occasionally seen this happen with moored buoys but not with Argo floats (in the UK).

In my experience, it's not possible to register/notify a float with OceanOPS if the WMO ID already exists... I expect Victor will know :0) . Maybe this is a temporary glitch that arose while the OceanOPS system was down earlier this year?

Cheers
Fiona

[ksato-aopc]

JAMSTEC has one float whose WMO no is 1902344.

[vturpin]

We need a bit more insight to really understand the issue. As we don't see duplicate at OceanOPS.

Could you confirm that the list of WMO below were already used when you tried to notify the float in the OceanOPS system or when you created the data/metadata files at GDAC ?
In that case, how did you fix the problem ? As Fiona said, this is not possible to register/notify a float if the WMO already exist.
How did you identify the issue ?

Some of these issues can be traced back to duplicate assignments in original distributions from OceanOps (that later got reconciled in one place, but took longer to resolve in all places of the system).
Did you receive two times the same WMO ID for two differents registrations ? Can you share this duplication of assignement with us please ?

here is the list of floats:
1902344
2903863
2903865
3902557
4903745
5906966
5906967
5906968

[JohnEGilson]

5906966
5906967
5906968

As I previously mentioned these were assigned to SIO 2 years ago, and in the meantime were given (and used) by other groups.

2 of the 3 above WMO were assigned to a float that were deployed and netCDF were created at the GDAC under the aoml dac. I identified the issue (after the fact) through the GDAC ar_index_global_prof.txt file and asked for the files to be removed from the GDAC. This issue occurred during the ocean-ops shutdown.

I continue to receive error messages when submitting my meta text file to notify new deployments (or plans) via ocean-ops. Thus a hand search through the ocean-ops database is the only way to use the database.

[ksato-aopc]

1902344 was deployed at 25th June, 2024. When my colleague tried to notify its deployment via ocean-ops, she found that 1902344 already exists on ocean-ops. On the ocean-ops web sites, its information of deployment and configuration are correct, but its country and Argo program are incorrect. There is no duplication of this wmo number in the GDAC index files and the dac of this float is jma in the GDAC index files. So, I think there is no problem with the data distribution of it in GDAC.

[vturpin]

I will update the program on the OceanOPS website.

In this case, it is not a matter of duplication but rather an incorrect PROJECT_NAME allocation in the meta.nc file, I presume. Additionally, it is likely that either Orens or I registered this float in the system, not the program members who would have rectified the Program allocation.

FYI, we (OceanOPS) receive daily notifications when a float transmits data and is not yet registered in the AIC. Under those circumstances, we take the initiative to notify the float ourselves to remain up to date with the Argo array.

[vturpin]

I continue to receive error messages when submitting my meta text file to notify new deployments (or plans) via ocean-ops. Thus a hand search through the ocean-ops database is the only way to use the database.

@JohnEGilson could we plan a call to identify this issue ? We do not understand it very well here and I think we are reaching the limit of writting discussion here to make progress.

[ksato-aopc]

@vturpin Thank you for your update. I confirmed that its information was updated on your web site. I apologize that my float issue was different from the issue that Tanya originally wanted to discuss.