Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

Problems using ERA5 variables with depthBelowLandLayer in ungrib.exe (WRF/WPS 4.1)

Cata_OC

New member
Hola a todos,


Estoy trabajando con datos ERA5 para correr WRF 4.1 en WPS 4.1 (sistema HPC con Linux), y se enfrenta a un problema persistente al intentar procesar variables de suelo (temperatura del suelo, humedad del suelo, etc.) que están etiquetadas con typeOfLevel = DepthBelowLandLayer.
El objetivo es generar un error que incluye variables de suelo como stl1–4 y swvl1–4, pero al ejecutar ungrib.exe con el Vtable estándar Vtable.ECMWF, obtengo el siguiente met.log (se los adjunto)
Esto ocurre incluso si los archivos GRIB están correctamente descargados y contienen todas las variables requeridas. Revisé los campos con grib_ls y efectivamente las variables de tipo DepthBelowLandLayer están presentes.
Intenté solucionarlo aplicando un grib_filter para reemplazar typeOfLevel, pero el filtro genera errores como:
ERROR DE ECCODES: Analizador: error de sintaxis en la línea 1 de filter_surface.rules

También probé unificar los datos con otros modelos (GFS) para suplantar las variables de suelo, pero debido a la configuración de WPS (no recompilable en mi entorno), necesito trabajar con los GRIB tal como están estructurados actualmente.
Mis preguntas son:
  1. ¿Existe alguna forma de adaptar correctamente el Vtable para leer variables con DepthBelowLandLayer?
  2. ¿Es posible transformar estos campos a superficie o capa entre dos profundidades con grib_filter sin perder integridad de datos?
  3. ¿WRF soporta directamente estos campos o es obligatorio reemplazarlos con datos GFS o de otra fuente?
Estoy trabajando en un entorno donde no puedo recompilar WPS, así que agradezco cualquier solución compatible con la estructura actual.
Agradezco mucho de antemano cualquier sugerencia o experiencia que puedan compartir.
Saludos,
Catalina Oyarzo Caroca
Estudiante de Ingeniería Civil Química – Universidad de Santiago de Chile
 

Attachments

  • metgrid.log
    443.6 KB · Views: 0
Hello everyone,


I’m working with ERA5 data to run WRF 4.1 with WPS 4.1 (HPC system on Linux), and I’m facing a persistent issue when trying to process soil variables (soil temperature, soil moisture, etc.) that are tagged with typeOfLevel = depthBelowLandLayer.
My goal is to generate a wrfout file that includes soil variables such as stl1–4 and swvl1–4, but when I run ungrib.exe using the standard Vtable.ECMWF, I get the following met.log (attached).
This happens even though the GRIB files are correctly downloaded and contain all the required variables. I checked the fields using grib_ls and confirmed that the depthBelowLandLayer fields are present.
I tried solving the issue by applying a grib_filter to replace typeOfLevel, but the filter returns syntax errors such as:

ECCODES ERROR: Parser: syntax error at line 1 of filter_surface.rules
I also tried merging the data with other models (like GFS) to substitute the soil variables, but due to my WPS configuration (which I cannot recompile), I need to work with the GRIB files as they are currently structured.
Here are my questions:
  1. Is there a way to correctly adapt the Vtable to read variables with depthBelowLandLayer?
  2. Is it possible to transform these fields to surface or layerBetweenTwoDepths using grib_filter without compromising data integrity?
  3. Does WRF support these fields directly, or is it mandatory to replace them with data from GFS or another source?

I’m working in an environment where recompiling WPS is not an option, so I would appreciate any solution that is compatible with the current structure.
Thank you in advance for any advice or experience you can share.


Best regards,
Catalina Oyarzo Caroca
Chemical Civil Engineering Student – University of Santiago, Chile
 
Hi,
Would you please download the pythin script era5_to_int.py from the website:

Then run this script following the instruction.

This scrip is specifically developed for processing ERA5 and produce intermediate files. By using this script, we don't need to worry for Vtable and soil information, etc.

Please try and let me know if you still have any issues.
 
Last edited:
Top