[Wrf-users] Wrf-users Digest, Vol 93, Issue 9

yingli zhu yingli at mail.usf.edu
Mon May 21 15:57:25 MDT 2012


Dear V.Yesubabu,
1. The machine is a PC with 8 processors.
2. I have changed the time in the file 2000-03-02_00:0:00:00.0000.4DVAR and I can see the data is processed during the assimilation. Thank you for your suggestion.
By comparing the new run and old run, the new attached running result shows that it runs longer and further than the last one, but it still collapses again.
Appreciate your valuable reply.

Yingli



On May 21, 2012, at 12:01 PM, V.YesuBabu wrote:

> Dear Yingli,
> As you mentioned, there is no error in rsl. files, 
> I would like to know two things for your problem and one suggestion after seeing your rsl.out.0000 
> my doubts are 
> 1.Whether 4DVAR experiment you are conducting on personal PC or Cluster.
> 2. if you are submitting in Linux cluster through PBS/IBM scheduler , it seems your wall-clock time exceeding issue, could be the reason.
> It is working for the same options to me. You can see my 4DVAR namelist.input attacched in the mail for more information. 
> 
> My observation/suggestion after seeing your rsl.out.0000,
> Your observations at final time"2000-03-02_00:00:00.0000" are not assimilating.
> just see your rsl.out.0000 file 
> *************************************************************************************
>    ob time  7
>       sound                  0 global,       0 local
>       synop                  0 global,       0 local
>       pilot                  0 global,       0 local
>       satem                  0 global,       0 local
>       geoamv                 0 global,       0 local
>       polaramv               0 global,       0 local
>       airep                  0 global,       0 local
>       gpspw                  0 global,       0 local
>       gpsrf                  0 global,       0 local
>       metar                  0 global,       0 local
>       ships                  0 global,       0 local
>       ssmi_rv                0 global,       0 local
>       ssmi_tb                0 global,       0 local
>       ssmt1                  0 global,       0 local
>       ssmt2                  0 global,       0 local
>       qscat                  0 global,       0 local
>       profiler               0 global,       0 local
>       buoy                   0 global,       0 local
>       bogus                  0 global,       0 local
>       pseudo                 0 global,       0 local
>       radar                  0 global,       0 local
>       radiance               0 global,       0 local
>       airs retrieval         0 global,       0 local
>       sonde_sfc              0 global,       0 local
>       mtgirs                 0 global,       0 local
>       tamdar                 0 global,       0 local
>       rain                   0 global,       0 local
> 
> **********************************************************************************
> The reason for this is 4DVAR won't accept observations at exact 6th hour i.e.,observations at "2000-03-02_00:00:00.0000"  in obs_gts_2000-03-02_00.4DVAR,
> please check once by changing time tag from "2000-03-02_00:00:00.0000" to "2000-03-01_23:55:00.0000"  in the file          2000-03-02_00:0:00:00.0000.4DVAR,  then it will accept observations at 6hr will also assimilate. 
> 
> 
> 
> with regards,
> V.Yesubabu,
> CES Group,
> CDAC,Pune. 
> 
> 
> On 21 May 2012 20:56, yingli zhu <yingli at mail.usf.edu> wrote:
> Dear V.Yesubabu,
> It does work following your suggestion. Thank you very much.
> But it just stops at some time during integration and does't show any wrong information.
> Do you have any idea about this problem?
> I attached the rsl files
> Best regards,
> Yingli
> 
> 
> 
> On May 19, 2012, at 1:47 AM, V.YesuBabu wrote:
> 
>> Dear Yingli,
>> The same error I got, while running 4DVAR with version 3.4 two weeks back,  I could overcome the problem by using 6hourly boundary files instead of 3houly.  Probably in the WRFDA3.4 not accepting 3hourly boundary files when hourly observations are supplied for 6hour interval. I think your error will be resolved,  if try using 6houlry GFS files in WPS and WRF and change option in 4DVAR namelist.input from "interval_seconds=10800" to "interval_seconds=21600"   (Or) supply hourly observations  for 3hourly by changing 4DVAR namelist.input "time_window_min="2000-03-01_18:00:00.0000", time_window_max ="2000-03-01_21:00:00.0000" 
>> 
>> 
>> with regards,
>> V.Yesubabu,
>> CES Group,
>> CDAC,Pune. 
>> 
>> 
>> On 18 May 2012 23:30, <wrf-users-request at ucar.edu> wrote:
>> Send Wrf-users mailing list submissions to
>>        wrf-users at ucar.edu
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>        http://mailman.ucar.edu/mailman/listinfo/wrf-users
>> or, via email, send a message with subject or body 'help' to
>>        wrf-users-request at ucar.edu
>> 
>> You can reach the person managing the list at
>>        wrf-users-owner at ucar.edu
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Wrf-users digest..."
>> 
>> 
>> Today's Topics:
>> 
>>   1. 4dvar error for V3.4 (yingli zhu)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Fri, 18 May 2012 10:27:01 -0400
>> From: yingli zhu <yingli at mail.usf.edu>
>> Subject: [Wrf-users] 4dvar error for V3.4
>> To: wrfhelp Help <wrfhelp at ucar.edu>
>> Cc: wrf-users at ucar.edu
>> Message-ID: <BBED383E-5F0E-4281-8D32-DBBEEB2BF04D at mail.usf.edu>
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> Hi,
>> I try to run 4dvar of version 3.4 and get this error:  "lateral boundary update is not allowed"
>> For the version 3.3, it works, but when I transferred to v3.4, this occurred.
>> Any suggestion?
>> Attached is the namelist.input and error message.
>> Yingli
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: rsl.out.0000
>> Type: application/octet-stream
>> Size: 13600 bytes
>> Desc: not available
>> Url : http://mailman.ucar.edu/pipermail/wrf-users/attachments/20120518/a99be560/attachment-0002.obj
>> -------------- next part --------------
>> 
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: namelist.input
>> Type: application/octet-stream
>> Size: 2042 bytes
>> Desc: not available
>> Url : http://mailman.ucar.edu/pipermail/wrf-users/attachments/20120518/a99be560/attachment-0003.obj
>> 
>> ------------------------------
>> 
>> _______________________________________________
>> Wrf-users mailing list
>> Wrf-users at ucar.edu
>> http://mailman.ucar.edu/mailman/listinfo/wrf-users
>> 
>> 
>> End of Wrf-users Digest, Vol 93, Issue 9
>> ****************************************
>> 
>> _______________________________________________
>> Wrf-users mailing list
>> Wrf-users at ucar.edu
>> http://mailman.ucar.edu/mailman/listinfo/wrf-users
> 
> 
> 
> <namelist.input>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/wrf-users/attachments/20120521/a6f912b9/attachment-0002.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rsl.out.000_new
Type: application/octet-stream
Size: 195714 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/wrf-users/attachments/20120521/a6f912b9/attachment-0001.obj 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/wrf-users/attachments/20120521/a6f912b9/attachment-0003.html 


More information about the Wrf-users mailing list