Replacement logic implementation

[VeikoAunapuu]

Requirements from EMF req3: https://eepublicdownloads.entsoe.eu/clean-documents/CIM_documents/Grid_Model_CIM/EMF%20requirements%20specification%20v3_Approved.pdf section 6.7.1

Scope: STEP 1. Use an IGM of the same time horizon of the same energy delivery day following the priority defined in Table 1. STEP 2. If not available, use an IGM from the same energy delivery day (other time horizon in consecutive order4), following the priority defined in Table 1. STEP 3. If not available, use an IGM from the same time horizon of older models of the same day type (working day, Saturday, Sunday), season and scenario type (peak, valley), following the priority defined in Table 1. Handling holidays is established based on the per-TSO request and provided via centralized approach, by using either previous day, Saturday, or Sunday data (single option or define prioritization). It is a prerequisite to have the holiday definitions per TSO/IGM and an indication if the substitution strategy should consider previous day, Saturday, or Sunday data and if the prioritization should be set. STEP 4. If not available, use older files of a different day type, following the priority defined in Table 1, considering the following general principles: for working days prioritize Saturday over Sunday, for Saturday prioritize Sunday over closest working days, and for Sunday prioritize Saturday over closest working days.

• [x] #51
• [ ] Expand to step 2 and 3
• [ ] Include AC position threshold check (6.7.1.2)

{
  "configuration": {
    "validity_start": "2024-02-22T00:00:00Z",
    "validity_end": "2024-02-22T23:59:59Z",
    "timeZone": "CET"
  },
  "timeHorizon": {
    "Request_list": ["ID", "1D", "2D", "WK"]
  },
  "hours": [
    {
   "hour": "00:30",
     "priority": 
        [
        {1: "P0H"},
                {2: "PT1H"},
                {3: "-PT1H"},
        {4: "-PT2H"}
        ]
    },
    {
    "hour": "01:30",
     "priority": 
        [
        {1: "P0H"},
                {2: "PT1H"},
                {3: "-PT1H"},
        {4: "-PT2H"}
        ]
    }
    ],
  "days":[
     {
   "day": "1",
     "priority": 
        [
        {1: "-P3D"},
                {2: "-P4D"}
        ]
    },
    {
   "day": "6", 
     "priority": 
        [
        {1: "-P7D"},
                {2: "-P14D"}
        ]
    }
  ]

}

[Haigutus]

Just to recap:

1. Request data for given day, apply mapping on same process type
2. If data missing, apply mapping to different process type data on same day
3. If data missing, Request data for similar day and apply mapping same process type
4. If data missing, apply mapping to different process type data on same day

Open questions

1. Where to get full list of TSO-s to be merged (eg what could be available) - initial idea was to first ask list of TSO available within x (2w) period
2. How to handle daylight saving?
3. If data not replaced found in step 4. - shall we exclude TSO or should we try any model that has solved by them in past 2W

[VeikoAunapuu]

1. Excluding areas that are already valid. Added request to clarify. Also exclude timeHorisons based on configuration list.
2. For DST changed the times to periods in reference to the current time (PT1H etc.)
3. New version checks all so after last step if model is not there it is not included.
4. Added to conf the weekday setting to also add priority of models not for the target day.