# OPERA the Radar Project
## 4 Discussion  
Definition of a manufacturer-independent data model has been an unprecedented success story. The OPERA data model has been used in international radar data exchange and re-analysis beyond the borders of Europe (e.g., in Australia). The first versions were very accommodating, allowing easy conversion from all the different manufacturer-specific formats; even the identifier of a radar can be given in five ways. Now, as the use of radar data has expanded from exchange between members or organizations to assimilation, verification, and data fusion in various communities, there is more pressure to tighten the use of the model, in order for it to be more homogeneous. The OPERA program has responded to this by allocating a new work package for homogenisation of the metadata. Each of the participating institutes has defined the use of its radars primarily for its own uses, within the boundary conditions of the hardware and data transfer capacity. Creation of an international composite has resulted in a natural pressure to homogenise the radar network. Sharing best practises in expert meetings has led to the same direction. The level of homogeneity can be considered a great achievement, in view of the heterogeneity of the hardware and measuring circumstances. The different brands and ages of the radars can be compared to those of cars in Europe: If we were to dictate that everyone must run at the same speed, we should force the Ferraris to slow down to Trabant speed, or agree that Trabants can never reach the Ferrari standard. It is important to note that these changes have happened gradually, and that the OPERA archives contain data from the early years, when the number of non-precipitating echoes was larger and the number of participating radars smaller. The heterogeneity of the time-series can be a risk, if used for climate studies. Much of the improvement in quality is related to better cancellation of non-precipitating echoes. This is most important for two user groups: Assimilation in numerical weather prediction models, and in extrapolation-based nowcasting. Assimilation of radar reflectivities can compensate for the known spin-up problem of many limited area NWP models: They tend to have too much precipitation at the beginning of the run, and it is valuable if the radars can tell the models where it is not raining. Nowcasting systems calculate motion vectors by comparing two consecutive radar images. Many clutter pixels are permanent and, thus, give false information of zero movement of the precipitating system. Even with a centralized quality control, the quality of the composites is still not perfect and, most alarmingly, the processing has destroyed some real precipitation data. Meanwhile, several members upgraded their radars and could locally use very advanced signal processing techniques. Hence, in March 2017, a new agreement was made: Everyone was to send their best possible data, documenting how it was processed, and the unfiltered data (TH) as a separate parameter. This decision has been implemented gradually. Improvements to the composites which have been studied, but not yet implemented, include the vertical profile of reflectivity, and changing the \(Z-R\) relationship, according to water phase (snow or rain). It has also become obvious that there are disparate user needs: Some applications need advanced quality control and production of complicated products, while others need the data as soon as possible. Hence, from 2019, the OPERA project has focused on development of three separate production lines: One for rapid processing, one for good quality, and one for independent processing (e.g., outside of the OPERA data centers). [PERSON] wrote the original draft for Introduction, Sections 2.1 and 3.3 and Discussion. [PERSON] and [PERSON] performed the data analysis for Section 3.1 and wrote the original drafts for those paragraphs. [PERSON] lead the work for Section 3.2. [PERSON] lead development for Section 2.2. [PERSON] and [PERSON] contributed in writing the text of Section 2.2.