[Wrf-users] Adaptive Time-step output times mismatch/incorrect

[Kevin Matthew Nuss]

Hi All,

I checked the code. The subroutine to adapt time steps is no longer called
for NESTED domains unless at a boundary update time, so it is not able to
adapt the time step to hit the output time, except for the outer domain.

Here is the 3.1.1 code in solve_em.F when it worked:

    ! Adaptive time step: Added by T. Hutchinson, WSI  3/5/07
    !   In this call, we do the time-step adaptation and set time-dependent
lateral
    !   boundary condition nudging weights.
    !
       IF (config_flags%use_adaptive_time_step) THEN
        CALL adapt_timestep(grid, config_flags)
         adapt_step_flag = .TRUE.
       ELSE
         adapt_step_flag = .FALSE.
       ENDIF
    ! End of adaptive time step modifications

And here is the equivalent code in 3.2.1:

    ! Adaptive time step: Added by T. Hutchinson, WSI  3/5/07
    !   In this call, we do the time-step adaptation and set time-dependent
lateral
    !   boundary condition nudging weights.
    !
       IF ( (config_flags%use_adaptive_time_step) .and. &
            ( (.not. grid%nested) .or. &
            ( (grid%nested) .and. (abs(grid%dtbc) < 0.0001) ) ) )THEN
          CALL adapt_timestep(grid, config_flags)
          adapt_step_flag = .TRUE.
       ELSE
          adapt_step_flag = .FALSE.
       ENDIF
    ! End of adaptive time step modifications

The variable dtbc is descripbed as:  "TIME SINCE BOUNDARY READ." Since I
don't know the purpose of the changes, I won't suggest changing 3.2.1 to
look like 3.1.1

I also looked at the code related to the configuration variable
"adjust_output_times". To me it looks like the output string for the file
name is changed when this is "true" but not the timestep or anything else.

Kevin Nuss


On Mon, Jun 28, 2010 at 3:05 PM, Zulauf, Michael <
Michael.Zulauf at iberdrolausa.com> wrote:

> FYI, I've seen this exact issue with 3.2 also (and _only_ 3.2).  I've
> had a couple emails with wrfhelp (the last being about a month ago), but
> haven't heard back as to whether they were able to reproduce or
> otherwise shed some light on this issue.  I expect they're busy.  But
> I'll ping them again here.   ;-)
>
> I've been planning to try a different set of compilers, and see if that
> makes any difference.  But I've been busy too.
>
> So, no help, but at least you're not alone.
>
> Mike
>
>
> -----Original Message-----
> Date: Fri, 25 Jun 2010 11:17:35 -0700
> From: Rahul Mahajan <rahulm at atmos.uw.edu>
> Subject: Re: [Wrf-users] Adaptive Time-step output times
>        mismatch/incorrect
> To: David Ovens <ovens at atmos.washington.edu>
> Cc: wrf-users at ucar.edu
> Message-ID:
>        <AANLkTikc8pDwNWZhHCtmbP0LrJ6m8Sy0chrsCp7pzqGC at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> David,
> It does look like the way you say. So, I suppose the issue is someplace
> else.
>
> Thanks,
> Rahul.
>
> On Fri, Jun 25, 2010 at 11:09 AM, David Ovens
> <ovens at atmos.washington.edu>wrote:
>
> > Rahul,
> >
> > I am not sure if this bug is the same that I found earlier in 3.2,
> > since I noticed an output bug with a time_step of 216 seconds and
> > adaptive time stepping was turned off.  But, take a look at your
> > external/esmf_time_f90/ESMF_Clock.F90 around line 1024.  It should
> > look like this:
> >
> >              IF ( ( .NOT. ( pred1 ) ) .AND. &
> >                   ( ( pred2 ) .OR. ( pred3 ) ) ) THEN
> >                 alarm%alarmint%Ringing = .TRUE.
> > !                 alarm%alarmint%PrevRingTime =
> clock%clockint%CurrTime
> >                 alarm%alarmint%RingTimeSet = .FALSE.  !it is a one
> time
> > alarm, it rang, now let it resort to interval
> > #if 1
> > ! logic above is sufficient to set the PrevRingTime, it is now.
> >                 IF ( positive_timestep ) THEN
> >
> > I hope that does it for you.
> >
> > David
> *****************************
>
>
>
>
> This message is intended for the exclusive attention of the address(es)
> indicated.  Any information contained herein is strictly confidential and
> privileged, especially as regards person data,
> which must not be disclosed.  If you are the intended recipient and have
> received it by mistake or learn about it in any other way, please notify us
> by return e-mail and delete this message from
>  your computer system. Any unauthorized use, reproduction, alteration,
> filing or sending of this message and/or any attached files to third parties
> may lead to legal proceedings being taken. Any
> opinion expressed herein is solely that of the author(s) and does not
> necessarily represent the opinion of Iberdrola. The sender does not
> guarantee the integrity, speed or safety of this
> message, not accept responsibility for any possible damage arising from the
> interception, incorporation of virus or any other manipulation carried out
> by third parties.
>
> _______________________________________________
> Wrf-users mailing list
> Wrf-users at ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/wrf-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/wrf-users/attachments/20101022/5bf7ce04/attachment.html