...
"algorithm": {
"phase": "execution", <--- do not touch
"config_name": "HybridLasso_test", <---- HERE
"description": "HybridLasso"
}
The writing of the trained model is working locally, let see if other fixings are needed once we run them on the cluster.
...
Please update/change whatever is needed.
"flare_history_window": 24 <--- we add this field to set the time interval (in hours) in which we check the occurance of a flare in the past.
It works if at least one item of the following dictionary is set to true
"flare_history_features": {"flare_past": true, "flare_index_past": true}
dataset": { "cadence":"24h",...
Shaun: Cristina Campi not a problem, these are important thoughts and questions to have! Just a random thought off the top of my head - I would think that a 12-hr cadence forecast would have to be a combination of, e.g., a "window":12, "issuing":"00" trained system and a second "window":12, "issuing":"12" trained system. Right now, if "issuing" is set to "XX" and we leave "window":24 then this means that the engine would need to filter the full property DB for the occurrence of timestamps of 12XX:00 UT and build a 24-hr forecast training just based on a just that different SHARP timestamp. For now, we do not need to worry about this because our focus is on 24-hr forecasts with 0-hr latency from 00:00 UT - I just want there to be the algorithmic structure available to parameterize these changes in case we have time to do it.
...