Read EcoSpold 2 mathematicalRelation formulas - #215
Merged
Conversation
EcoSpold 2 datasets define exchange amounts as formulas over dataset parameters and exchange variable names, but the parser ignored both: <parameter> elements were dropped and formulas were invisible. Parse <parameter> variables onto the activity (resolved value plus raw formula, the same fields the SimaPro parser already fills) and re-evaluate each exchange's mathematicalRelation against the dataset-local environment once the file is fully read, since the variables it references may be declared after the exchange. A formula that evaluates replaces the stored amount; one that doesn't (unknown variable, unsupported function, cross-dataset reference) keeps the stored amount and is reported as a load-time warning rather than silently ignored. Nested <property> attributes are excluded from capture the same way property amounts already are.
The evaluator covers only a subset of the EcoSpold 2 formula language (no UnitConversion, no cross-dataset Ref) with SimaPro-flavoured semantics, while stored amounts are pre-evaluated by the editor that wrote the dataset. Overriding a stored amount with our re-evaluation could corrupt data whenever the two disagree for evaluator reasons rather than staleness, so the formula result is now a consistency check: a divergence warns and keeps the stored value. Real databases use unsupported functions heavily, so unevaluable formulas are summarized in one warning per dataset instead of one per exchange. A <parameter> carrying a variableName but no usable amount is now dropped with a warning instead of silently.
…l-relation # Conflicts: # CHANGELOG.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
EcoSpold 2 datasets carry their calculation logic in
mathematicalRelationattributes:<parameter>elements declare variables, and an exchange's amount can be defined as a formula over them. The parser ignored all of it — parameters were dropped on the floor and formulas were invisible, so a consumer could never inspect how an amount was derived, and a stored amount inconsistent with its formula went unnoticed. The SimaPro path already evaluates formulas throughExpr; this brings EcoSpold 2 formula reading onto the same machinery.What it does now
<parameter>variables land on the activity: the resolved value inactivityParamsand the raw formula inactivityParamExprs— the same fields the SimaPro parser fills. A parameter with avariableNamebut no usable amount is dropped with a warning.mathematicalRelationis checked after the whole dataset is read (its variables may be declared later in the file), against a dataset-local environment: the dataset's parameters plus every exchange's ownvariableNamebound to its stored amount.UnitConversion, no cross-datasetRef) with SimaPro-flavoured semantics, so its result serves as a consistency check: a formula that evaluates to a different value is reported as a divergence warning, never applied.<property>are excluded from exchange capture, the same way property amounts already were.Cross-dataset variable resolution is out of scope: everything is resolved within one dataset.
Tests
New
mathematicalRelation formulasgroup inEcoSpold2Spec: divergence keeps the stored amount and warns, parameter storage on the activity, the unresolvable-variable fallback, the dropped-parameter warning, and the property-attribute no-leak case. Full suite: 1555 examples, 0 failures.