Changing the interpretation of unitUnitEffLevel. The model was reading the...

Changing the interpretation of unitUnitEffLevel. The model was reading the input data so that 'effLevel to start aggregation' meant the start of the next level (e.g. using level3 resulted in the last time step of level3 in the internal parameter lastStepNotAggregated - in effect pointing to the start of Level4). Now this is read so that level3 means the start of level3

inc/3a_periodicInit.gms

@@ -184,7 +184,7 @@ loop(m,
 * --- Calculate 'lastStepNotAggregated' for aggregated units and aggregator units ---
 
     loop(effLevel$mSettingsEff(m, effLevel),
-        loop(effLevel_${mSettingsEff(m, effLevel_) and ord(effLevel_) < ord(effLevel)},
+        loop(effLevel_${mSettingsEff(m, effLevel_) and ord(effLevel_) <= ord(effLevel)},
             p_unit(unit_aggregated(unit), 'lastStepNotAggregated')${ sum(unit_,unitUnitEffLevel(unit_, unit, effLevel)) }
                 = mSettingsEff(m, effLevel_);
             p_unit(unit_aggregator(unit), 'lastStepNotAggregated')${ sum(unit_,unitUnitEffLevel(unit, unit_, effLevel)) }

[Niina Helistö]

In my simulations, the logic was earlier that level3 means the start of level3. And this update changes the logic so that level3 means the start of level4. So I'm not quite sure about this update. There can be problems when the user wants start the simulation with aggregated units, but I'm not sure whether those situations can be correctly handled by the previous version or the version with this update. Maybe we need to add an issue about that?