You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is no meaningful functional difference between physical and economic allocation-- all it does is choose one flow property or another to determine allocation factors. But at present it is left to the app to figure out which flow property to use.
For instance, the user manual says: " In order for allocation to work, the main product and the co-products of the multioutput process need to have the same flow property." In other words, the app is inspecting the process and deciding what property to use for allocation. Similarly, for economic allocation the flow property being used is unclear, but is apparently required to be "Market value, bulk prices," leading to problems like this one. and leading to annoyances if using a process whose flows are not characterized by that quantity.
The proposed solution would be to replace "physical | economic | causal" allocation to be "allocation by property | causal", and if "allocation by property" is chosen, then the UI offers a drop-down for all eligible properties, i.e. all properties that are characterized for all reference flows, being physical, economic, social, whatever. Then the user picks the quantity to use. This also has the advantage of providing immediate feedback to the user about how the allocation calculation is being performed.
By the way, I would also recommend a more tolerant allocation algorithm that does not require all outputs to be characterized by the same flow property, but simply assigns allocation factors of zero to all flows not characterized by the designated property. In this case, "all eligible properties" would be any property that appears on any reference flow, not any property that appears on all reference flows.
The text was updated successfully, but these errors were encountered:
I think the problem with the economic allocation factors is related to the fact that the products need to have a common flow property which is tagged as economic (which is the case for Market value, bulk prices but not limited to that)…
But I agree (and +1): selecting the property that should be used for the calculation of the factors (with a more tolerant algorithm) would be much better.
I would still keep the categories economic, physical, and causal because this is then used in the calculation setup of a product system to decide which factors should be selected in the calculation for the respective processes (where each process could have different properties from which these allocation factors are derived).
Also note that the factors can be set/edited manually and that there is also this issue #31.
There is no meaningful functional difference between physical and economic allocation-- all it does is choose one flow property or another to determine allocation factors. But at present it is left to the app to figure out which flow property to use.
For instance, the user manual says: " In order for allocation to work, the main product and the co-products of the multioutput process need to have the same flow property." In other words, the app is inspecting the process and deciding what property to use for allocation. Similarly, for economic allocation the flow property being used is unclear, but is apparently required to be "Market value, bulk prices," leading to problems like this one. and leading to annoyances if using a process whose flows are not characterized by that quantity.
The proposed solution would be to replace "physical | economic | causal" allocation to be "allocation by property | causal", and if "allocation by property" is chosen, then the UI offers a drop-down for all eligible properties, i.e. all properties that are characterized for all reference flows, being physical, economic, social, whatever. Then the user picks the quantity to use. This also has the advantage of providing immediate feedback to the user about how the allocation calculation is being performed.
By the way, I would also recommend a more tolerant allocation algorithm that does not require all outputs to be characterized by the same flow property, but simply assigns allocation factors of zero to all flows not characterized by the designated property. In this case, "all eligible properties" would be any property that appears on any reference flow, not any property that appears on all reference flows.
The text was updated successfully, but these errors were encountered: