...
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| name / question | What was the biggest technical challenges to be able to participate in S2S/TIGGE projects at the beginning? What could improve next time? | What are the biggest challenges in the current production phase to ensure long-term minimal effort operations? How could the data archive centres support you more in that role? | How could we improve cooperation between data providers and archiving centres (how to communicate/automate tasks/implement checking tools/test/implement model upgrades etc)? | What are good/bad features in the design of S2S/TIGGE databases (data format/structure/encoding/compression etc)? | What are good/bad features in the interfaces for getting S2S/TIGGE data (web portals/Web API/direct MARS access etc)? | What would be the most welcomed technical update of S2S/TIGGE databases from user point of view (data formats/data access/new products like time-series etc)? | Do you know other data archives from similar projects which could be inspiring next time (information exchange/interoperability/data standards etc)? | Are you generally satisfied with the way the S2S/TIGGE databases have been created and supported until now? What would you like to change or improve the most? |
| Harry Hendon (BoM) | Reprocessing the POAMA hindcasts from netcdf to grib wih the specific structure as requested (eg continuous accumulated fields). This took us ~6 months to process the POAMA hindcasts, which at the time was the largest hindcast set that went into S2S. There were a lot of variables requested as well, which I am sure some won't be examined by most researchers. Although is was not as difficult, we had problems setting up the real time transfer. If it were u[p to us, we would request a smaller subset of data, and in netcdf. | We have now upgraded to a new model with a completely different architecture (we have gone from spectral to gridpoint), so we essentially have to start from scratch to generate S2S outputs. We have no resources internally to create the S2S output from our hindcasts. The new model has a 4 fold increase in resolution, so the data volume is larger (although we don't have as many ensemble members). Because of all of this, BoM will not contribute to S2S for next 2-3 years, due to lack of manpower and computing resources (cpu and storage) at our end to convert output. We haven't even begun to discuss how we will set up the real time feed, in light of the new security on BoM operational machines. | Not sure how to comment, other than after all the careful checking we did with converting POAMA, there are now obviously errors in some of the fields in the S2S archive. | We have minimal experience downloading data from the archive, but what we have done so far has been pretty straightforward, once you understand the process. | NC | More obvious where are derived products like the RMM indices. | NC | Support seems to be outstanding. |
| Daniele M. | reforecasts preparation | any operational issue can impact products for archives | notify each time even everything went well (email? some status files??) | |||||
| Frederic V. | on behalf of many providers - problems with conversion to GRIB2 from NetCDF etc Next time conversion tools could be shared among the centres (using NetCDF..) (even within one organisation links to other projects are important (KMA, BoM, CMA..)) Conversion to accumulated params since the beginning is additional work (common tool?) | TIGGE high resolution is really needed? (some stats could help; limited domain with high res?) | to share available used tools and ideas (encoding check; value limits checks; input file checks (number of fields..)) | |||||
| CMA | conversion from NetCDF was a challenge | |||||||
| JMA | numerous S2S variables | |||||||
| fixed forecast computation is big job after each model upgrade (CPU, storage) | ||||||||
| Michael D. | samples will be prepared for TIGGE; CXML conversion is needed; GRIB2 should be OK | |||||||