Comments (30)
There must have been previous UM configs which write these fields. I'll have a trawl through rosie to see if there's a suitable suite from which we can mirror their STASH.
from canari-data.
corresponding stash (from u-cm829 - the CMIP6 suite):
hus7h.6hrPlevPt [1]: Specific Humidity {groups: 2, vars: 16} --- (30, 295)
psl.6hrPlevPt [1]: Sea Level Pressure {groups: 4, vars: 8} --- stash: m01s16i222, lbproc: 0
ta7h.6hrPlevPt [1]: Air Temperature {groups: 2, vars: 18} --- (30, 294)
ua7h.6hrPlevPt [1]: Eastward Wind {groups: 2, vars: 17} --- (30, 201)
va7h.6hrPlevPt [1]: Northward Wind {groups: 2, vars: 17} --- (30,202)
zg7h.6hrPlevPt [1]: Geopotential Height {groups: 2, vars: 12} --- (30, 297)
on PLEV7H ?
we don't currently output tos.Omon [1]: Sea Surface Temperature,
siconc:original_name = "mo: (variable_name: aice)" ; -- we output aice daily and monthly means
from canari-data.
PLEV7H are the following pressure levels: 925, 850, 700, 600, 500, 250, 50
Looking at u-ce297 a UKESM job outputting CORDEX variables, what we require are:
cx-6hr (instantaneous values)
ua7h 00 002 DALLRH T6HR UP7
va77 00 003 DALLRH T6HR UP7
ta7h 30 111 DALLTH T6HR UP7
zg7h ???
hus7h 00 010 DALLRH T6HR UP7
psl 00 409 DIAG T6HR UP7
Extra:
orog 00 033 DIAG T6HR UP7
There's obviously some post-processing required as the 3D fields are written out on model levels, which need to be converted to PLEV7H. I don't know why these are written out directly on these levels as STASH. Also there doesn't appear to be a pressure/height field, but I think that can be derived from the model level metadata/psl/orograrphy?
The suite only appears to write out the 3D instantaneous fields. I now seeing if I can spot the other fields in the job.
from canari-data.
Aren't the sectn 30 alternatives already processed?
from canari-data.
Yes, that's why I'm wondering why the model level versions are used. Conspiracy or cock-up?
from canari-data.
Could be that it allows you to interpolate the data onto an arbitrary set(s) of pressure levels in post-processing.
from canari-data.
...and not worry about the heaviside function.
from canari-data.
Assuming that cx-6hr (instantaneous values)
are used for creating lateral boundary conditions for RCMs, it's a bit odd that they're on pressure levels, and that there's only seven of them.
Ignore if I've got the wrong end of the stick.
from canari-data.
Possibly to make them portable across the RCM models and the data sizes as small as possible? Speaking of which, writing out model levels will take 10x as much space as the single set of pressure levels.
from canari-data.
Looking at u-cn134, our base CANARI job, it appears the 3D pressure level STASH is there, but turned off, and written out on two extra levels. Look for PLEV9H and T6HR.
Also a quick comment, in Grenville's list above, 201 and 202 are on the UV grid, but 294, 295 and 297 are on the T grid.
from canari-data.
my list is a bit dodgy - I hadn't looked in 6hrPlevPt CMIP6 output
from canari-data.
what's the story with the heaviside function?
from canari-data.
If they're required on the same grid then it's
hus7h.6hrPlevPt [1]: Specific Humidity {groups: 2, vars: 16} --- (30, 205)
psl.6hrPlevPt [1]: Sea Level Pressure {groups: 4, vars: 8} ???
ta7h.6hrPlevPt [1]: Air Temperature {groups: 2, vars: 18} --- (30, 204)
ua7h.6hrPlevPt [1]: Eastward Wind {groups: 2, vars: 17} --- (30, 201)
va7h.6hrPlevPt [1]: Northward Wind {groups: 2, vars: 17} --- (30,202)
zg7h.6hrPlevPt [1]: Geopotential Height {groups: 2, vars: 12} --- (30, 207)
Plus,maybe, Heaviside 30,301 (required for masking)
from canari-data.
psl.6hrPlevPt is stash: m01s16i222, lbproc: 0
from canari-data.
This is what CMIP6 says (all on PLEV7H):
hus7h.6hrPlevPt [1]: Specific Humidity {groups: 2, vars: 16} --- (30, 295 lbproc 0) & stash: m01s30i304
psl.6hrPlevPt [1]: Sea Level Pressure {groups: 4, vars: 8} --- m01s16i222, lbproc: 0
ta7h.6hrPlevPt [1]: Air Temperature {groups: 2, vars: 18} --- (30, 294 lbproc 0) & ( m01s30i304)
ua7h.6hrPlevPt [1]: Eastward Wind {groups: 2, vars: 17} --- (30, 201 lbproc 0) & m01s30i301
va7h.6hrPlevPt [1]: Northward Wind {groups: 2, vars: 17} --- (30,202 lbproc 0) & m01s30i301
zg7h.6hrPlevPt [1]: Geopotential Height {groups: 2, vars: 12} --- (30, 297 lbproc 0) & m01s30i304
from canari-data.
and the daily fields
prw.Eday [1]: Water Vapor Path stash: m01s30i461, lbproc: 128
clt.day [1]: Total Cloud Cover Percentage stash: m01s02i204, lbproc: 128
tslsi.day [1]: Surface Temperature Where Land or Sea Ice ?????????????
hurs.day [1]: Near-Surface Relative Humidity stash: m01s03i245, lbproc: 128
hus.day [1]: Specific Humidity stash: m01s30i295 blev: [1000.0, 850.0, 700.0, 500.0, 250.0, 100.0, 50.0, 10.0], lbproc: 128 & stash: m01s30i304
huss.day [1]: Near-Surface Specific Humidity stash: m01s03i237, lbproc: 128
pr.day [1]: Precipitation stash: m01s05i216, lbproc: 128
psl.day [1]: Sea Level Pressure stash: m01s16i222, lbproc: 128
siconc.SIday [1]: Sea-Ice Area Percentage (Ocean Grid aice
ta.day [1]: Air Temperature stash: m01s30i294, blev: [1000.0, 850.0, 700.0, 500.0, 250.0, 100.0, 50.0, 10.0], lbproc: 128 & stash: m01s30i304,
tas.day [1]: Near-Surface Air Temperature stash: m01s03i236, lbproc: 128
tasmax.day [1]: Daily Maximum Near-Surface Air Temperature see above
tasmin.day [1]: Daily Minimum Near-Surface Air Temperature see above
tos.Oday [1]: Sea Surface Temperature sst (added)
ua.day [1]: Eastward Wind stash: m01s30i201, blev: [1000.0, 850.0, 700.0, 500.0, 250.0, 100.0, 50.0, 10.0], lbproc: 128 & stash: m01s30i304,
uas.day [1]: Eastward Near-Surface Wind stash: m01s03i209, lbproc: 128
va.day [1]: Northward Wind stash: m01s30i202, blev: [1000.0, 850.0, 700.0, 500.0, 250.0, 100.0, 50.0, 10.0], lbproc: 128 & stash: m01s30i301
vas.day [1]: Northward Near-Surface Win stash: m01s03i210, lbproc: 128
zg.day [1]: Geopotential Height stash: m01s30i297, blev: [1000.0, 850.0, 700.0, 500.0, 250.0, 100.0, 50.0, 10.0], lbproc: 128 & stash: m01s30i301
from canari-data.
I'm still surprised that anyone would want to drive an RCM from LBCs with no lower boundary layer resolution (925 hPa is +/- 615m) above mean sea level) and with vertical gradients all but destroyed after a double interpolation :)
from canari-data.
Yes, well, I stuffed up. We missed out one of the bits of the data request (being a bit that points at bits required by other experiments). Unfortunately it's big. I suspect it means we will have to consider either not writing this stuff out for all ensemble members, or for all times, or a combination of both. Meanwhile, here is the output of my scanner:
== CMIP6/CMIP/MOHC/HadGEM3-GC31-MM/historical/r1i1p1f3/ ==
6hrPlevPt:hus:specific_humidity:Specific Humidity: (1440, 7, 324, 432)
6hrPlevPt:psl:air_pressure_at_mean_sea_level:Sea Level Pressure: (1440, 324, 432)
6hrPlevPt:ta:air_temperature:Air Temperature: (1440, 7, 324, 432)
6hrPlevPt:ua:eastward_wind:Eastward Wind: (1440, 7, 325, 432)
6hrPlevPt:va:northward_wind:Northward Wind: (1440, 7, 325, 432)
6hrPlevPt:zg:geopotential_height:Geopotential Height: (1440, 7, 324, 432)
6hrLev:hus:specific_humidity:Specific Humidity: (360, 85, 324, 432)
6hrLev:ps:surface_air_pressure:Surface Air Pressure: (7200, 324, 432)
6hrLev:ta:air_temperature:Air Temperature: (360, 85, 324, 432)
6hrLev:ua:eastward_wind:Eastward Wind: (360, 85, 324, 432)
6hrLev:va:northward_wind:Northward Wind: (360, 85, 325, 432)
Eday:prw:atmosphere_mass_content_of_water_vapor:Water Vapor Path: (1800, 324, 432)
day:clt:cloud_area_fraction:Total Cloud Cover Percentage: (1800, 324, 432)
day:hurs:relative_humidity:Near-Surface Relative Humidity: (1800, 324, 432)
day:hus:specific_humidity:Specific Humidity: (1800, 8, 324, 432)
day:huss:specific_humidity:Near-Surface Specific Humidity: (1800, 324, 432)
day:pr:precipitation_flux:Precipitation: (1800, 324, 432)
day:psl:air_pressure_at_mean_sea_level:Sea Level Pressure: (1800, 324, 432)
day:ta:air_temperature:Air Temperature: (1800, 8, 324, 432)
day:tas:air_temperature:Near-Surface Air Temperature: (1800, 324, 432)
day:tasmax:air_temperature:Daily Maximum Near-Surface Air Temperature: (1800, 324, 432)
day:tasmin:air_temperature:Daily Minimum Near-Surface Air Temperature: (1800, 324, 432)
day:ua:eastward_wind:Eastward Wind: (1800, 8, 325, 432)
day:uas:eastward_wind:Eastward Near-Surface Wind: (1800, 324, 432)
day:va:northward_wind:Northward Wind: (1800, 8, 325, 432)
day:vas:northward_wind:Northward Near-Surface Wind: (1800, 325, 432)
day:zg:geopotential_height:Geopotential Height: (1800, 8, 324, 432)
Oday:tos:sea_surface_temperature:Sea Surface Temperature: (1800, 1205, 1440)
SImon:siconc:sea_ice_area_fraction:Sea-ice Area Percentage (Ocean Grid): (60, 1205, 1440)
Omon:tos:sea_surface_temperature:Sea Surface Temperature: (60, 1205, 1440)
(Missing ['day/tslsi', 'SIday/siconc'])
SMLE Volume 1029TB
Volume Planning
group: 6hrPlevPt, volume 90.7TB
group: 6hrLev, volume 901.9TB
group: Eday, volume 0.9TB
group: day, volume 30.1TB
group: Oday, volume 5.6TB
group: SImon, volume 0.1TB
group: Omon, volume 0.2TB
Total SMLE Volume 1029TB (years 150, members 40)
Volume Planning
group: 6hrPlevPt, volume 36.3TB
group: 6hrLev, volume 360.7TB
group: Eday, volume 0.4TB
group: day, volume 12.0TB
group: Oday, volume 2.2TB
group: SImon, volume 0.0TB
group: Omon, volume 0.1TB
Total SMLE Volume 412TB (years 60, members 40)
from canari-data.
Grenville did query this, and I talked absolute nonsense in reply! Sorry. These are the culprits:
6hrLev:hus:specific_humidity:Specific Humidity: (360, 85, 324, 432)
6hrLev:ps:surface_air_pressure:Surface Air Pressure: (7200, 324, 432)
6hrLev:ta:air_temperature:Air Temperature: (360, 85, 324, 432)
6hrLev:ua:eastward_wind:Eastward Wind: (360, 85, 324, 432)
6hrLev:va:northward_wind:Northward Wind: (360, 85, 325, 432)
which together, if we wrote them out for everything, would be 900 TB if I've done my sums right.
from canari-data.
Will any CORDEX data we do provide will have to go through CMOR/be CMOR-complient so that the people running the RCMs can use it?
from canari-data.
I think if it is fully CF compliant (which it will be), and if it uses our cut-down attributes, it will be ok for everyone.
I need to do some due diligence now, because we can't currently afford to do this for all members for the entire duration.
from canari-data.
6hrLev:hus:specific_humidity:Specific Humidity: (360, 85, 324, 432) m01s00i010
6hrLev:ps:surface_air_pressure:Surface Air Pressure: (7200, 324, 432) m01s00i409
6hrLev:ta:air_temperature:Air Temperature: (360, 85, 324, 432) m01s30i111
6hrLev:ua:eastward_wind:Eastward Wind: (360, 85, 324, 432) m01s00i002
6hrLev:va:northward_wind:Northward Wind: (360, 85, 325, 432) m01s00i003
from canari-data.
That, (plus orog) is basically what u-ce297, which I mentioned above, writes for its CORDEX output.
from canari-data.
Why does it need extra daily/monthly fields?
from canari-data.
Having got this wrong previously, I now believe this is to aid in inter-comparison and evaluation. The sea ice fields which were not provided by the MOHC for CMIP6 (['day/tslsi', 'SIday/siconc'])) seem very much to be "nice to have" for just one group, so missing those is no big deal.
from canari-data.
So we have the 6 hourly model level fields (ua(U),va(V),ta(T),hus(SH))+ 6 hourly surface pressure ps(PMSL), and no explicit height/pressure field, and no sea ice. What about SSTs? are these tas?
from canari-data.
we have daily sst and ice from NEMO, CICE resp.
from canari-data.
CANARI has bunch of data on 9 pressure levels
I wonder if that's by design?
from canari-data.
Added all this -- watch XIOS throw a fit
from canari-data.
CORDEX stash works OK - it looks like there is no needs to mask pressure level data with the heaviside function - the fields are already masked
from canari-data.
Related Issues (20)
- RCM data products
- cf aggregation not working properly: cf-python issue or metadata issue?
- Consider what to do with the RCM boundary files.
- Consider what to do with the start dumps
- Need to develop a tape pool strategy. HOT 2
- Finalise the distribution of variables between streams (and output files) HOT 1
- Sort out formal experiment description HOT 1
- canari further_info_url HOT 2
- extra simulations for initialisation - where are they and how documented HOT 1
- atmosphere lat-long bounds HOT 15
- realms HOT 5
- cmip table names HOT 6
- first cycle checkpoint code HOT 1
- grab initialization index to set ensemeble number in atmos&ocean file names HOT 2
- WIP CMIP6plus list HOT 1
- CICE/NEMO cell_methods HOT 9
- NEMO zonal/basin data
- NEMO standard names are mostly wrong HOT 1
- CICE data problems HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from canari-data.