Escenario 20c3m

[gutierjm]

Hola, he estado mirando en oceano y los escenarios del 20c3m están guardados desde 1850 en algunos casos. En principio sólo necesitamos 1950-2000 así que podemos borrar el resto de información. ¿Hay algo que se me escapa?.
De esta manera podríamos tener más runs de 20c3m.

[carmen]

Hola Jose, si entras en alguno de los escenarios que esten desde el año 1850, verás que probablemente solo haya una o dos variables, son variables que se pidieron después de hacer la última limplieza de los años, de todas formas la idea es borrarlo, aunque no nos van a proporcionar mucha capacidad porque son muy poquitos datos. Si no te parece mal, dejo pendiente el borrado hasta que hagamos la division por años de los nuevos datos, por si se generan más de estos..

[gutierjm]

OK. Lo dejamos pendiente y cuando se corten los otros datos borras los directorios 1850-1950

[carmen]

Perfecto!!

[gutierjm]

Carmen, lo dejo abierto hasta que lo cierres definitivamente cuando se haya hecho después de recortar, etc.

[SwenBrands]

Hola chicos,

Los ficheros del HADGEM ocupan tanto espacio por la alta resolución del modelo. Un ejemplo:

HADGEM_20C3M_1_6H_ua850_hour00_01011948_30121999.nc

en

oceano.macc.unican.es\gmeteo\DATA\CERA\HADGEM\descargas\Swen\20C3M

oucpa unos 1,92GB, son sólo datos a las 00 UTC

Sin embargo, un fichero que ya vendría con los datos interpolados a la rejilla rectangular de 2,5º de los datos públicos del ERA40 ocuparía sólo unos 383 MB - ésta es la diferencia. Ya sé lo de la maxima del grupo, Antonio, y sé que me pongo un poco pesado, pero si me dejases interpolar los datos ANTES de bajarlos (en el blizzard-cluster del DKRZ) no tendríamos estos problemas. Cambiaría también los headers según la tabla 128 y solucionaría el problema de los distintos unidades. Finalmente podríamos leer los datos con la función getFieldfromGRIB.m (o por allí) de MeteoLab?...más fácil imposible!

Quiero decir: Si ya sabemos de antemano que vamos a interpolar la rejilla de los GCMs a la rejilla ERA, por qué no lo hacemos ANTES de bajar los datos. Carmen, a qué resolución necesitarías los datos de GCM? Si ahora me dices que 2,5º te bastan y somos nosotros los dos los únicos que trabajan que éstos datos (según la "encuesta" de la última reunión) me pregunto por qué no tocar los datos! Sobre todo teniendo en cuenta que en un año con el CMIP5 cambia todo.

Cordiales saludos,

Swen

[antonio]

Los datos que mencionas teien una resolución de 1.875 en longitud y 1.25 en latitud.
Si los interpolasemos a una resolución de 2.5º que es la que tienen los datos de ERA40 ocuparían más o menos (me puedo haber equivocado, comprueba los números):

1.92GB*(1.875*1.25/(2.5*2.5))=0.720GB 

De todas formas los datos de ERA40 que tenemos están a 1.125º, que es aproximadament la resolución nativa de los datos ERA40:

1.92GB*(1.875*1.25/(2.5*2.5))=3.556GB 

Cuál es el formato original, sin post-procesar, que hay el en Blizard del DKRZ? me puedes conseguir un fichero? (importante, tiene que ser sin postprocesar).

Ten encuenta que no estás bajando los datos, solo para "tu experimento", si no para que podamos incluirlos en el portal, para otros posibles usuarios.

Antonio
Replying to SwenBrands:

Hola chicos,

Los ficheros del HADGEM ocupan tanto espacio por la alta resolución del modelo. Un ejemplo:

HADGEM_20C3M_1_6H_ua850_hour00_01011948_30121999.nc

en

oceano.macc.unican.es\gmeteo\DATA\CERA\HADGEM\descargas\Swen\20C3M

oucpa unos 1,92GB, son sólo datos a las 00 UTC

Sin embargo, un fichero que ya vendría con los datos interpolados a la rejilla rectangular de 2,5º de los datos públicos del ERA40 ocuparía sólo unos 383 MB - ésta es la diferencia. Ya sé lo de la maxima del grupo, Antonio, y sé que me pongo un poco pesado, pero si me dejases interpolar los datos ANTES de bajarlos (en el blizzard-cluster del DKRZ) no tendríamos estos problemas. Cambiaría también los headers según la tabla 128 y solucionaría el problema de los distintos unidades. Finalmente podríamos leer los datos con la función getFieldfromGRIB.m (o por allí) de MeteoLab?...más fácil imposible!

Quiero decir: Si ya sabemos de antemano que vamos a interpolar la rejilla de los GCMs a la rejilla ERA, por qué no lo hacemos ANTES de bajar los datos. Carmen, a qué resolución necesitarías los datos de GCM? Si ahora me dices que 2,5º te bastan y somos nosotros los dos los únicos que trabajan que éstos datos (según la "encuesta" de la última reunión) me pregunto por qué no tocar los datos! Sobre todo teniendo en cuenta que en un año con el CMIP5 cambia todo.

Cordiales saludos,

Swen

[gutierjm]

Hola Swen,

2 GB es muy manejable en oceano. Por tanto, no te preocupes en recortarlos ni en interpolarlos. Cuando lo tengas listo díselo a Antonio y una vez que ellos hayan desarrollado las funciones de lectura podrás acceder a los datos, etc. Un poco de paciencia :)

[SwenBrands]

Tienes razón Antonio, la relación del espacio ocupado por el fichero original y postprocesado es aprox. 5:1 en el caso del HADGEM1! Para acceder Los datos no postprocesados mira el ticket #44!

El fichero no es de todo original porque tal y como hemos dicho he cortado los valores a las 06, 12 y 18 UTC de entre 01/01/1948 y 01/01/1999.

un saludo

Swen

Replying to antonio:

Los datos que mencionas teien una resolución de 1.875 en longitud y 1.25 en latitud.
Si los interpolasemos a una resolución de 2.5º que es la que tienen los datos de ERA40 ocuparían más o menos (me puedo haber equivocado, comprueba los números):

1.92GB*(1.875*1.25/(2.5*2.5))=0.720GB 

De todas formas los datos de ERA40 que tenemos están a 1.125º, que es aproximadament la resolución nativa de los datos ERA40:

1.92GB*(1.875*1.25/(2.5*2.5))=3.556GB 

Cuál es el formato original, sin post-procesar, que hay el en Blizard del DKRZ? me puedes conseguir un fichero? (importante, tiene que ser sin postprocesar).

Ten encuenta que no estás bajando los datos, solo para "tu experimento", si no para que podamos incluirlos en el portal, para otros posibles usuarios.

Antonio
Replying to SwenBrands:

Hola chicos,

Los ficheros del HADGEM ocupan tanto espacio por la alta resolución del modelo. Un ejemplo:

HADGEM_20C3M_1_6H_ua850_hour00_01011948_30121999.nc

en

oceano.macc.unican.es\gmeteo\DATA\CERA\HADGEM\descargas\Swen\20C3M

oucpa unos 1,92GB, son sólo datos a las 00 UTC

Sin embargo, un fichero que ya vendría con los datos interpolados a la rejilla rectangular de 2,5º de los datos públicos del ERA40 ocuparía sólo unos 383 MB - ésta es la diferencia. Ya sé lo de la maxima del grupo, Antonio, y sé que me pongo un poco pesado, pero si me dejases interpolar los datos ANTES de bajarlos (en el blizzard-cluster del DKRZ) no tendríamos estos problemas. Cambiaría también los headers según la tabla 128 y solucionaría el problema de los distintos unidades. Finalmente podríamos leer los datos con la función getFieldfromGRIB.m (o por allí) de MeteoLab?...más fácil imposible!

Quiero decir: Si ya sabemos de antemano que vamos a interpolar la rejilla de los GCMs a la rejilla ERA, por qué no lo hacemos ANTES de bajar los datos. Carmen, a qué resolución necesitarías los datos de GCM? Si ahora me dices que 2,5º te bastan y somos nosotros los dos los únicos que trabajan que éstos datos (según la "encuesta" de la última reunión) me pregunto por qué no tocar los datos! Sobre todo teniendo en cuenta que en un año con el CMIP5 cambia todo.

Cordiales saludos,

Swen