Opened 2 weeks ago

Last modified 10 days ago

#280 accepted Enhancement

Trajectory time 240000 instead of 000000 next day

Reported by: hcpxvi Owned by: pesei
Priority: minor Milestone: FLEXTRA 6
Component: FLEXTRA Version: FLEXTRA 5
Keywords: Cc:

Description (last modified by pesei)

This is a bit of a corner case. When running FLEXTRA in STARTFLIGHT mode, one of my start points happened by pure chance to be

20200103 000000 

(FWIW, the vertical unit here is 3 : pressure in hPa)

In the output file, the trajectory header line comes out as

DATE: 20200102    TIME:  240000    STOP INDEX: 4    # OF POINTS:  383

It would be preferable if this were to be written out as

DATE: 20200103    TIME:       0    STOP INDEX: 4    # OF POINTS:  383

Change History (3)

comment:1 Changed 2 weeks ago by pesei

  • Description modified (diff)
  • Owner set to pesei
  • Status changed from new to accepted
  • Type changed from Defect to Enhancement

comment:2 Changed 2 weeks ago by pesei

I have verified that caldate.f (also caldate.f90 used in FLEXPART) returns hour 24 if the input Julian date is slightly before midnight, because no check is carried out on that, and rounding may lead to such a result.

Some intermediate calculations in the subroutine are done in single-precision real. However, changing them to double does not solve the problem which is embedded in

  if (ss.eq.60) then  ! 60 seconds = 1 minute
  if (mi.eq.60) then

without then checking on hh.eq.24. Doing so is not trivial, though, as then one may need to update also month and year, with all the complications of leap years. One should better do rounding before, eg

!PS if-block inserted to avoid result with hh-24
  if ((xjuldate-julday)*86400._dp .ge. 86399.5_dp) then
    xjuldate = xjuldate + xjuldate-julday-86399.5_dp/86400._dp

comment:3 Changed 10 days ago by pesei

Coiuld you implement that in your version?

Note: See TracTickets for help on using tickets.
hosted by ZAMG