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

Segfault in real.exe with ERA5 input

wszeliga

New member
Hi all,
I'm trying to use ERA5 surface and pressure level data as initial and boundary conditions for a WRF run, but I'm running into trouble when running real.exe. The error message is:

Code:
flag_soil_layers at end of optional_lsm_levels is  1
flag_soil_levels at end of optional_lsm_levels is  0
st_levels_input =   3  17  64 194
sm_levels_input =   3  17  64 194
sw_levels_input =   3  17  64 194
med_sidata_input: back from init_domain
med_sidata_input: calling init_domain
 checking boundary conditions for grid
 boundary conditions OK for grid
 Missing surface u wind, replaced with closest level, use_surface set to false.
 Missing surface v wind, replaced with closest level, use_surface set to false.
Using sfcprs  to compute psfc

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f177e678960 in ???
#1  0x7f177e677ac5 in ???
#2  0x7f177e21f51f in ???
#3  0x5628546bcd48 in wrf_message_.part.0
#4  0x56285421e723 in __module_initialize_real_MOD_lagrange_setup
#5  0x562854220883 in __module_initialize_real_MOD_vert_interp
#6  0x56285427c3ce in __module_initialize_real_MOD_init_domain_rk
#7  0x5628542e9969 in __module_initialize_real_MOD_init_domain
#8  0x562854207488 in med_sidata_input_
#9  0x5628542083c7 in MAIN__
#10  0x5628541beff2 in main

The full output from real.exe is in the attached real.log. I've also attached a python script to download data from Copernicus (account required) that reproduces these results as well as the ungrib and metgrid output logs. Ungrib was run with Vtable.ECMWF. The SHA256 checksum for the ERA5_INVARIANT file that I am using is:

Code:
SHA256(ERA5_INVARIANT)= 3ef32ec48296986dc987b22a840cdc18d859d396796bb5fe67c6eea7ab8acf51

This is using WRF v 4.4 on Linux and I have successfully used HRRR and GFS initial and boundary conditions in the past on this machine. Any ideas how to proceed?
 

Attachments

  • metgrid.log
    1.3 MB · Views: 2
  • namelist.input
    3.3 KB · Views: 3
  • namelist.wps
    1,017 bytes · Views: 3
  • real.log
    177.6 KB · Views: 1
  • ungrib.log
    558.2 KB · Views: 2
  • download.py.txt
    2.7 KB · Views: 4
Hi,
Have you used this exact same namelist for successful runs in the past? Without some deeper diving, it's hard to say what is causing the segmentation fault, but there are a few things I can see if your namelist that, if they aren't yet, will probably cause some issues in the future.

Code:
run_hours                           = 24,
 run_minutes                         = 0,
 run_seconds                         = 0,
 start_year                          = 2010, 2010,
 start_month                         = 03,   03,
 start_day                           = 31,   31,
 start_hour                          = 00,   00,
 end_year                            = 2010, 2010,
 end_month                           = 03,   03,
 end_day                             = 31,   31,
 end_hour                            = 23,   23,

1. This shouldn't cause an issue, but if you are planning to run wrf for 24 hours, why are you making the end time for real.exe after 23 hours? If you need 24 hours, you should change that to end on 4/1.

Code:
debug_level                         = 200,

2. Please set this to 0. debug_level is rarely useful and just adds a lot of junk to the output files, making them very large and difficult to read through.

Code:
e_we                     = 40,       22,
e_sn                     = 40,       22,

3. Your domains are way too small. In order to create reasonable results, domains should be no smaller than 100x100 grid points. Take a look at this Best Practice page that discusses reasonable domain set-ups.

4. Finally, to address the issue you're seeing in the real.log,


Looking at your ungrib.log, it does look like you're missing the UU and VV data at the surface (level 200100), as well as surface pressure. Here, X indicates the data is found, while O means it is not.

Code:
2024-01-06 20:46:30.475 --- INFORM: RRPR: hdate = 2010-03-31_00:00:00
2024-01-06 20:46:30.475 --- Inventory for date = 2010-03-31 00:00:00
2024-01-06 20:46:30.475 ---      PRES     GEOPT       HGT        TT        UU        VV        RH     DEWPT   LANDSEA   SOILGEO   SOILHGT      PSFC
2024-01-06 20:46:30.476 --- -------------------------------------------------
2024-01-06 20:46:30.476 ---    200100         O            O             X           O         O           X         X                 O               X               X                  O

Whereas, when I process ERA5 data, I see the following

Code:
2024-01-11 17:09:18.137 --- INFORM: RRPR: hdate = 2020-08-30_15:00:00
2024-01-11 17:09:18.137 --- Inventory for date = 2020-08-30 15:00:00
2024-01-11 17:09:18.137 ---      PRES     GEOPT       HGT        TT        UU        VV        RH     DEWPT   LANDSEA   SOILGEO   SOILHGT      PSFC
2024-01-11 17:09:18.137 --- -------------------------------------------------
2024-01-11 17:09:18.137 ---    200100         O               O           X         X            X           X           X             O                O                O                X

What Vtable are you using? I used Vtable.ERA_interim.pl. If you aren't using that one, give that a try, but it's likely that you truly are missing those surface fields and you'll need to get them.
 
Thanks @kwerner the missing surface pressure and 10m U and V fields were the culprit. In the download.py script, I needed the following additional variables, '10m_u_component_of_wind', '10m_v_component_of_wind', rather than the 'neutral' versions of those variable, and 'surface_pressure' in my API call to the 'reanalysis-era5-single-levels' dataset. I've expanded my domain sizes (they were just trial values to get through the real.exe step) and was able to successfully process using ERA5.
 
Hi! I also use era5 pressure level and surface layer data to drive WRF. Can I ask you what command you use to link pressure and surface data?
I put my pressure level data and surface data as long with land-sea mask and geopotential girb data in one folder and use
ln -s ungrib/Variable_Tables/Vtable.ERA-interim.pl Vtable
to link. Is this correct? Thank you!
Thanks @kwerner the missing surface pressure and 10m U and V fields were the culprit. In the download.py script, I needed the following additional variables, '10m_u_component_of_wind', '10m_v_component_of_wind', rather than the 'neutral' versions of those variable, and 'surface_pressure' in my API call to the 'reanalysis-era5-single-levels' dataset. I've expanded my domain sizes (they were just trial values to get through the real.exe step) and was able to successfully process using ERA5.
 
Hi! I also use era5 pressure level and surface layer data to drive WRF. Can I ask you what command you use to link pressure and surface data?
I put my pressure level data and surface data as long with land-sea mask and geopotential girb data in one folder and use
ln -s ungrib/Variable_Tables/Vtable.ERA-interim.pl Vtable
to link. Is this correct? Thank you!

It looks like you're already asking about this topic in another thread: ln -s ungrib/Variable_Tables/Vtable.ERA-interim.pl Vtable Please only ask your question one time in the forum to prevent additional work for the admins. Thanks.
 
Top