[Wrf-users] RE: WRF NetCDF I/O XLAT/XLONG Shifted

Brent L Shaw bshaw at wdtinc.com
Fri Aug 3 09:47:37 MDT 2007


I must retract my cry for help!  I found the problem, and it was
"self-induced" by part of my processing stream that adds a new attribute
to the WRF output NetCDF files.  It turned out that occasionally my
script was adding this attribute before WRF had closed the file.  Sorry
if I got anybody else worried over this!

 

Best regards,

 

Brent

 

________________________________

From: wrfhelp [mailto:wrfhelp at ucar.edu] 
Sent: Saturday, July 21, 2007 5:27 PM
To: Brent L Shaw
Subject: Re: WRF NetCDF I/O XLAT/XLONG Shifted

 

Sorry, Brent. But we have not seen this. 

 

wrfhelp

 

On Jul 20, 2007, at 9:44 AM, Brent L Shaw wrote:





Hello all,

 

Today, one of our real-time runs experienced a somewhat random error
today.  In one of the output files (specifically, the 8-hour forecast
file [we write out 1 frame per file]), some sort of "memory shift"
apparently took place when writing the NetCDF file.  What happened is
that the last few elements of the XLAT array had some of the first few
elements from the XLONG array at the end, and the end of the XLONG array
has some of the XLAT values at the end.  I included snippets of the end
of these ncdumps below so you can see what I mean.   I only discovered
this because when animating some products from this run on GEMPAK, this
one particular forecast hour was shifted.  The problem only occurred in
this one output file. 

 

I saved all of the input data and reran the case manually with exactly
the same executable, same compute nodes, etc.  This time that file was
correct, so it appears to have been a random event (which scares me even
more).  Has anyone else ever seen something like this happen? 

 

In case it matters, this was done with the RSL_LITE DM with nesting
version of WRF 2.2, compiled with MPICH 1.2.7p1 built with pgf90 and
pgcc (version 7.0-5) running on an x86_64 AMD Opteron-based Linux
cluster.  The run was done using 5 processors (4 for domain
decomposition and 1 I/O node). 

 

Best regards,

 

Brent Shaw

 

<Last snipped of ncdump -v XLAT>

55.68303, 55.63144, 55.57923, 55.52641, 55.47297, 55.41893, 55.36428,

    55.30902, 55.25315, 55.19668, 55.13961, 55.08193, 55.02365,
54.96478,

    54.90531, 54.84525, 54.78459, 54.72334, -123.3628, -123.1758,
-122.9887,

    -122.8014, -122.6139, -122.4263, -122.2386, -122.0506, -121.8626,

    -121.6743, -121.486, -121.2974, -121.1088 ;

 

<Last snippet of ncdump -v XLONG>

-78.80542, -78.49875, -78.19275, -77.88736, -77.58264, -77.27859,

    -76.97522, -76.67249, -76.37045, -76.06909, -75.7684, -75.46841,

    -75.16913, -74.87051, -74.57263, -74.27542, 20.44331, 20.4799,
20.51613,

    20.55199, 20.58751, 20.62265, 20.65743, 20.69184, 20.72591,
20.75959,

    20.79292, 20.82587, 20.85846 ;

 





 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/wrf-users/attachments/20070803/61afad26/attachment.html


More information about the Wrf-users mailing list