Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Commodities may have different types per site #55

Open
ojdo opened this issue Mar 15, 2016 · 0 comments
Open

Commodities may have different types per site #55

ojdo opened this issue Mar 15, 2016 · 0 comments
Labels
discussion maintenance validation Issue should be included into validation.py

Comments

@ojdo
Copy link
Contributor

ojdo commented Mar 15, 2016

If a process has a site's demand commodity as its input, it can be basically consumed without having been imported/transmitted/generated from anywhere else.

Actually the problem lies deeper: it should not be allowed for a commodity to have different types in different sites, because that "outsmarts" the current logic of assigning a certain named commodity to the co_* subsets based of the existence of at least one site in which the commodity has that type.

Even more actually, this cries for separating commodity-wide information (like type) from commodity-site relations (like supply, price). Right now, the data model (one table for commodities only) allows for the upper inconsistency to occur without warning or error message, thus leading to logical 'holes' in the problem formulation.

@ojdo ojdo added the bug label Mar 15, 2016
@ojdo ojdo changed the title Demand commodities may be "pulled out of the air" Commodities may have different types per site Mar 15, 2016
@ojdo ojdo added maintenance and removed bug labels Aug 31, 2016
@lodersky lodersky added enhancement maintenance validation Issue should be included into validation.py and removed maintenance enhancement labels Jun 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion maintenance validation Issue should be included into validation.py
Projects
None yet
Development

No branches or pull requests

2 participants