Closed ellgil82 closed 3 weeks ago
Thank you for your input, Ella.
label
.label_extended
element allows for spaces and other marks. I would suggest to avoid underscores there. This element is intended for longer titles, or to build model description tables automatically. What about: "UK Met Office Unified Model version xx"?further_info_url
points to a private resource (user and password are requested). Would you have a public URL for your model version?"UK Met Office Unified Model" works well as an extended label. Happy to include version number too (vn 13.0) if you think that's appropriate here. Although note that lots of UM users use different model versions so if we could use a non-version specific label it might avoid duplication.
The UM is unfortunately a licensable model, but this public-facing website could be an alternative: https://www.metoffice.gov.uk/research/approach/modelling-systems/unified-model
The UM is a relative of HadREM3 (it's in the same family) but is sufficiently different that I think it necessitates a fresh label.
Thank you. I updated your original post.
No problem at all if the model is licensed. The further_info_url
does not need to point to the code or the full formulation, but just to an informative description of the specific model configuration, which would allow to distinguish it from potential future versions/configurations to be registered. In this sense, would this paper refer to the specific configuration you are using?
MetUM seems like the name of a modelling system which can be configured in many different ways (coupled to different components, using different dynamical cores, ...). The source_id
should be unique to a given model configuration (very slight changes could go in the realization part of the version_realization
element, though). No problem if many source_id
s need to be defined for MetUM. The key part is that users can understand the differences of the different configurations, to be able to interpret the results.
That said, I'm not sure if any other group will contribute to CORDEX with MetUM. Are you aware of other potential use of MetUM in other domains? Otherwise, we could just go ahead registering MetUM, as this model name was not used before in CORDEX and no other simulation plans to downscale CMIP6 use this name.
Great. There will at some point be a paper describing the specific description of the model that we are submitting to CORDEX, but currently the best model description would probably be this one: https://gmd.copernicus.org/articles/16/1713/2023/
source_id could include the version in that case, v13.0
I think you are right that no other groups will submit MetUM data to CMIP6 because this is the regional configuration and will only be used for CORDEX.
Thanks for your help!
No, I meant CORDEX-CMIP6. For the moment, there are no other MetUM model versions in CORDEX, but some could show up in other domains.
I replaced the further_info_url
with the paper you provided. I saw that there is also another name (RAL) for your model, so you could also go for something like MetUM-RAL3
, or RAL2-P
(if this is the polar version of the RAL2-M and RAL2-T mid-latitude and tropical configurations in the paper). Please, choose freely and let me know what fits best. According to what we've been discussing, any of the names is OK, including your original MetUM. Notice only that no dots are allowed in the source_id
so, to add the version, we would have something like MetUM13 or MetUMv13 or MetUM13-0 or ...
I think MetUM is probably best, because the various configurations of the regional physics (RA2M, RAL2-T etc.) can be turned on and off within the same model version. So I would suggest we go with MetUM and update the label to MetUMv13p0. Does that work?
/register
OK, let's go for it. Thank you!
label
MetUMv13p0
label_extended
UK Met Office Unified Model version 13.0
source_id
MetUM
source_type
ARCM
release_year
2022
activity_participation
DD
institution_id
BAS
further_info_url
https://doi.org/10.5194/gmd-16-1713-2023
What license do you choose?
CC BY 4.0