Ticket #451 (new Task)
coupling frequency units
| Reported by: | rupert | Owned by: | gerry |
|---|---|---|---|
| Priority: | minor | Milestone: | V1.2 Questionnaire release |
| Component: | WP6 - CMIP5 Questionnaire | Version: | |
| Keywords: | Cc: | ||
| Requirement: | http://metaforclimate.eu/Work-Package-2/Developing-the-CIM/Project-Requirements-summary.htm | ||
Description
The coupling frequency allows different units. This is good. However, the timestep of a component (if provided) is fixed to be in seconds in the mindmaps. The issue is how we convert the values if needed, seeing as different models can use different calendars. We might want to do this to know how many timesteps a component makes between coupling. Should we ask for calendar type for the components/model as well, or am I going over the top here?
Change History
comment:2 Changed 2 years ago by rupert
- Status changed from new to closed
- Resolution set to wontfix
The component timestep information is not being explicitly provided in the questionnaire (via the mindmaps). Rather it is a general component property that may or may not exist. Therefore the CIM element that captures the timestep of a component will not be populated. This means that it will not be possible to compare timestepping and coupling rates. Closing this ticket as won't fix.
comment:3 Changed 2 years ago by bryan
- Status changed from closed to reopened
- Resolution wontfix deleted
comment:4 Changed 2 years ago by bryan
- Owner changed from rupert to bryan
- Status changed from reopened to new
- Milestone changed from Release CMIP5 Questionnaire to D6.3 Human GUI
Reopen, as this is something that still needs thinking about, even if we don't put it in the current release of the questionnaire.
How many times does a calendar type actually impact on either timestepping or coupling? The only time this is likely to be a problem is with ESM into deep time, where seconds for timestepping might not be a good solution anyway? Is the problem in the mindmaps?