Modification to the Local Solar Time

[FatimaPillosu]

The local solar time has the following problems:

• Wrong units. They are currently saved as "UTC" and they should be indicated as "Hours (0 to 24)".

• Users shouldn't be able to change the units.

• The local solar time is saved amongst the "fixed" columns. It is a predictor, so it should be saved amongst the predictors to not confuse the users.

• When we use LST as a predictor, we should be able to modify the "addition" feature, as for example, for 6-h forecast we have to "shift" the hours (+3 hours, for example) and maybe other more complex operations (for example, if the value is less than 12, multiply it by 24, to move those hours at the end of the day and define better the breakpoints). In this example, we will then have local solar time from 12 to 36, where from 12 to 24 is the local solar time with no modification and from 24 to 36 is the local solar time from 0 to 12 but with an addition of 24h.

Please, contact Esti if it is not clear enough.

[EstiGascon]

Many thanks for implementing more flexibility in the Local Solar Time variable. I have 1 addition to the current changes, as they will be more useful for us:

• In the addition option, we would need to be able to select in which period of the Local solar time we want to apply this addition. For example, in general we want to apply an addition of 24h, but only for the Local solar time values from 0 to 12 h and not from 12 to 24h. Please, contact me if it is not clear.

[FatimaPillosu]

Hi @onyb ,
summarizing what we discussed before, we could have the following problems with circular variables:
one might want to merge the ends of the variable range (see example in yellow).

An idea could be having a button (in the computations section) that the user can click to indicate to the software whether that variable is a circular variable or not. If that button is ticked, then the user should be allowed to insert for the first threshold a value for Thr_L that it's bigger than ThrH (as shown in the example).

For the first line of thresholds (highlighted by the wider edges), the selection should then be:
variable(>ThrL) merge variable(<ThrH) (two groups of values are merged into one)
For the rest line of thresholds, the selection should be as normal (i.e. as done for the linear variables):
variable(>ThrL & <ThrH) (only one group of values is always selected)

Eventually, the file Breakpoints.csv will print the thresholds as they are (i.e. Thr_L=21 and Thr_H=3). The software to compute the forecasts will be changed to be able to read circular variables.

Hope this is all clear.

Cheers,

Fatima

[onyb]

It's not necessary to ask the user to input the period, in this case, 24 hours. The current algorithm is as follows:

if thrL > thrH:
    # periodic variable
    (variable > thrL) | (variable < thrH)
else:
    (variable > thrL) & (variable < thrH)

Note that the bitwise operator is different for periodic variables.

[onyb]

Fixed in v0.17.0.