search

serv-terr / pbl_met

"pbl_met" is a set of Fortran modules aimed at building meteorological processors and other software pertaining Planetary Boundary Layer (PBL) applications.
GNU Lesser General Public License v3.0
2 stars 1 forks source link

Ameriflux gold files: data starting on 30' boundaries are left unprocessed #67

Closed mafavaron closed 6 years ago

mafavaron commented 6 years ago

As from name

mafavaron commented 6 years ago

Get size after averaging is 2, as expected.

mafavaron commented 6 years ago

Get size after averages addition is 48, as expected.

mafavaron commented 6 years ago

On sonic data read, time stamps are generated correctly.

mafavaron commented 6 years ago

On eddy covariance data addition to multi-hour set, time stamp vectors get filled correctly, with a step of 1800s

mafavaron commented 6 years ago

Time stamp also makes sense in test program's second cycle, where data are retrieved for print.

mafavaron commented 6 years ago

Wind speed is zero, and rotation angle sin*cos NaN, on second element in each hourly block (EddyCovData % process(...)).

mafavaron commented 6 years ago

As a confirm, in each 30 minutes block the first element contains all 36000 data, while the second holds 0.

The bug is then in block indexing.

mafavaron commented 6 years ago

The ivTimeIndex vector within EddyCovData % addHourly(...) prints correct.

Is it really used, when saving data?

mafavaron commented 6 years ago

The retrieved ivNumData vector in EddyCovData % getHourly(...) is 36000, 0 - that is, incorrect: it should be 18000 instead.

The bug is then in averaging routine.

mafavaron commented 6 years ago

Within SonicData % averages(...), the value of ivTimeIndex is always 1 (not 2 as it should on last values based on a correct hourly time span.

mafavaron commented 6 years ago

Hourly time stamps, on entry to SonicData % averages(...), are all within 1800s from base time - they should be within 3600s. The problem is then with time stamp calculation? On read?

mafavaron commented 6 years ago

Bug was finally traced to the time stamp in AF gold files, as converted to SonicLib form. Their hourly time stamp is in fact restricted to 0..1799 instead of 0..3599.

mafavaron commented 6 years ago

Converter program modified, and whole chain tested. The problem reported is not present any longer. Closing issue.