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

Could not find level above ground

smeech84

Member
Hello,

I am having trouble processing CFSv2 data. I am using data to run WPS and WRF from:

/glade/campaign/collections/rda/data/d094000/

I have tried using both "pgrbh06" and "sfluxgrbf06" files and also just the "pgrbh06" file to run ungrib. Both ways result in the same error during real though:

d01 2019-07-10_06:00:00 Yes, this special data is acceptable to use: OUTPUT FROM METGRID V4.6.0
d01 2019-07-10_06:00:00 Input data is acceptable to use: met_em.d01.2019-07-10_06:00:00.nc
metgrid input_wrf.F first_date_input = 2019-07-10_06:00:00
metgrid input_wrf.F first_date_nml = 2019-07-10_06:00:00
d01 2019-07-10_06:00:00 Timing for input 0 s.
d01 2019-07-10_06:00:00 flag_soil_layers read from met_em file is 1
Bathymetry dataset from GEBCO Compilation Group. Please acknowledge the following in presentations and publications: GEBCO Compilation Group (2021) GEBCO 2021 Grid (doi:10.5285/c6612cbe-50b3-0cff-e053-6c86abc09f8f).
Max map factor in domain 1 = 0.98. Scale the dt in the model accordingly.
Using sfcprs2 to compute psfc
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 6825
Could not find level above ground
-------------------------------------------

I did look at the met_em* files and they do in fact have negative values in the 'PRES' variable:

PRES =
1.15104e+10, 1.15104e+10, 1.15104e+10, 1.15104e+10, 1.15104e+10,
1.15104e+10, 1.15104e+10, 1.15104e+10, 1.15104e+10, 1.15104e+10,
1.15104e+10, 1.15104e+10, 1.15104e+10, 1.15104e+10, 1.15104e+10,
1.15104e+10, 1.15104e+10, 1.15104e+10, 1.15104e+10, 1.132803e+10,
1.063356e+10, 1.000886e+10, 9.450185e+09, 8.953151e+09, 8.954047e+09,
9.088791e+09, 9.21779e+09, 9.341538e+09, 8.19247e+09, 3.924323e+09,
-3.973218e+08, -4.769385e+09, -9.185936e+09, -1.000131e+10,
-1.000131e+10, -1.000131e+10, -1.000131e+10, -1.000131e+10,
-1.000131e+10, -1.000131e+10, -1.000131e+10, -1.000131e+10,
-1.000131e+10, -1.000131e+10, -1.000131e+10, -1.000131e+10,
-1.000131e+10, -1.000131e+10, -1.000131e+10, -1.000131e+10,
-1.000131e+10, -1.000131e+10, -1.000131e+10, -1.000131e+10,
-1.000131e+10, -1.000131e+10, -1.000131e+10, -1.000131e+10,
-1.000131e+10, -1.000131e+10, -1.000131e+10, -1.000131e+10,
-1.000131e+10, -1.000131e+10, -1.000131e+10, -1.000131e+10,
-1.000131e+10, -1.000131e+10, -1.000131e+10, -1.000131e+10,
-1.000131e+10, -1.000131e+10, -1.000131e+10, -7.311031e+09,
-2.505559e+09, 2.2986e+09, 7.102759e+09, 1.15104e+10, 1.15104e+10,

I looked at different times from the files contained in the NCAR collections and they all seemed to show these negative values and cause issues. I am pretty sure I have used these CFSv2 files from this archive in the past with no issues but I seem to be having problems this time. What else could I do to correct this problem? Is it the data stored here?

Thanks,
Scott
 
Hi Scott,
Apologies for the delay in response. Since the NCAR RDA data also include the negative values, I would check with their team to see if they can offer any thoughts or solutions. If you did figure it out and have time, please come back and post the resolution in case others runs across this in the future. Thanks!
 
Top