GitLab

Now the criteria for daytime versus night or dawn/dusk is based on the solar
elevation. This works much better since now measurements problems such as snow
on a sensor lead to high cloudiness values (which is most probably the case,
otherwise the snow on the sensor would have melted) while keeping the improved
behavior at dusk/dawn that leads to more realistic values when interpolated over
the night. The performance plots will be redone with this new version.

Fabiano had some trouble with his stations, where the parametrized ILWR was
quite different from what it used to be a while ago. Actually, it turns out that
this would only be visible when explicitly configuring a data generator for All
Sky ILWR and when the measurements had some problems (lots of abnormally low
ISWR values, probably due to snow covering the sensor). These kind of issues
have not been seen at WFJ.

So for now, the ISWR threshold has been reverted to 5 W/m2 and the whole
cloudiness computation to this older version. This means that the results at
locations such as WFJ are degraded compared to some of the last commits.

Adding option NAMING to the USER spatialInterpolations algorithm

See merge request !5

Adding option NAMING to the USER spatialInterpolations algorithm, which allows to specify the file naming convention using YYYY for year, MM for month, DD for day, hh for hour, mm for minute, ss for seconds (optional) and PARAM for meteo parameter.

Several problems have been found when benchmarking the ILWR parametrizations at
the *WFJ station over the 2017-10-01 - 2021-10-01 period (with hourly data):

1. It happens surprisingly more often  than thought that ISWR_meas > ISWR_pot.
This was handled by returning nodata for the cloudiness, in order to temporally
interpolate (if possible) the cloudiness from neighboring points. This was
overly conservative and lead to degraded performance (for example when happening
before the night). Now in such a case the clearness index is reset to 1 so the
cloudiness gets set to a very low value or most often, zero.

2. There are even more problems around dawn/dusk than envisioned... So instead
of only computing the cloudiness when the radiation levels are above 5 W/m2, the
threshold is now 40 W/m2 (so if a sensor has some trouble with low solar
elevation it will not generate a very wrong cloudiness that would be used as a
basis for temporal interpolation over the night, thus generating a large number
of quite wrong data points). This threshold is now a public member of the
Atmosphere class in order to be broadly reused (for consistency).

3. Finally, it seems that the choice of cloudiness parametrization that
originally seemed a no-brainer is much more tricky... Officially, the clearness
index to cloudiness parametrization it tightly coupled with the cloudiness to
ILWR parametrization. But for our stations, even if not that far from one
another and is seemingly similar conditions, swapping cloudiness
parametrizations independently of the ILWR parametrization seem to make sense
for some cases. So this possibility has been added to the ILWR all sky
parametrization (by default, the cloudiness parametrization is the one that
belongs to the ILWR parametrization that has been chosen).

As inishell won't be bundled with MeteoIO anymore (but more the opposite), removing some unecessary code in the CMakeLists

Change to have IDW automatically interpolate wind speed components when...

See merge request !4

More acdd fields, more documentation and fixed a bug where the geospatial metadata were not written as expected

Please note that the ACDD_EMAIL key has been renamed into ACDD_CREATOR_EMAIL.

This seems to work but should definitely be validated at a location with ILWR
measurements. In the MeteoBlue plugin, the radiation fields now rely on their
"instant" variant that matches what we want so this can be compared to our
internally computed potential radiation (the backwards variants had a time
shift, so they are probably averages over the past period or something similar).
Also some minor optimizations in the MeteoBlue plugin (including requesting
compressed data transfers if possible and switching to https).

Otherwise subsequent MeteoData objects don't contain the same parameters...

A new option has been added to Smet, when writing data out: appending the current date to the filename.

This will allow multiple versions of a given data set to be created (such as
with forecast data from various runs) and merged later one (keeping the latest
or the oldest of each duplicated timestamps). A new constructor has been added
to the Date class for convenience

Instead of giving it the highest priority, it can now be used with the lowest
priority, so as fallback if no other algorithm could provide data.

A first version of the MeteoBlue plugin that works quite well (but not all parameters are supported yet)

But there's a lot left to be done!!