Commit 942c77f0 authored by Juha Kiviluoma's avatar Juha Kiviluoma
Browse files

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
parent 8dd0e629
......@@ -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)) }
......
  • 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?

  • mentioned in issue #135 (closed)

    Toggle commit list
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment