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

Transformer which raises the temperature #97

Merged
merged 42 commits into from Feb 29, 2016

Conversation

Projects
None yet
2 participants
@uvchik
Copy link
Member

uvchik commented Feb 23, 2016

The aim of this feature is to transport energy from one bus to another while the buses may have different temperature level. So if the temperature of the input bus is lower than the temperature of the output bus external energy is used to heat up the flow.

A new bus class has to be created named HeatBus that has an attribute for the temperature and the return flow temperature.

Furthermore a transformer is needed that has two inputs (storage-bus, external energy) and one output. The output might be a bus for district heating with temperatures between 80 and 120°C. The storage bus might be a "low" temperature bus with a temperature below 100°C (unpressurised). The external energy might be gas, oil, electricity, etc..

@uvchik

This comment has been minimized.

Copy link
Member Author

uvchik commented Feb 23, 2016

The additional device will heat up the flow and therefore will deliver an amount of energy. This amount depends on the temperature difference between the buses and the temperature difference between the input bus and the return flow temperature.

eq2

eq3

Then the amount of all input flows multiplied with their efficiency will be the output flow. The efficiency of the each will be calculated so that the sum of the efficiency of both flows might be greater than one.

eq1

f=\frac{T^{flow}_{bus,o}-T^{flow}_{bus,i}}{T^{flow}_{bus,i}-T^{return}_{bus,o}}

w_{e,i_{e,1}}(t)=w_{e,i_{e,2}}(t)\cdot f,\forall e,\forall t

w_{e,i_{e,1}}(t)\cdot\eta_{e,i_{e,1}}(t)+w_{e,i_{e,2}}(t)\cdot\eta_{e,i_{e,2}}(t)=w_{e,o_{e}},\forall e,\forall t

@uvchik uvchik added the enhancement label Feb 23, 2016

@uvchik uvchik added this to the February 2016 release milestone Feb 23, 2016

@uvchik uvchik self-assigned this Feb 23, 2016

uvchik added some commits Feb 23, 2016

@uvchik

This comment has been minimized.

Copy link
Member Author

uvchik commented on a065031 Feb 24, 2016

Click on the commit here ⬆️ because this is a commit-comment 😄

If investment=True and an input rule is used an error message is raised. Sometimes the in_max value exists but is set to 'inf' or even to 'None' or it does not exist but can exist. In all these cases the error is still raised. I think this should not be the case so I check for 'None' and 'inf' values before raising an error.

@simonhilpert Is it okay for you?

This comment has been minimized.

Copy link
Member

simnh replied Feb 24, 2016

I am not sure what you are trying to avoid. You can't use side="input" because this isn't implemented. No matter what. Even if in_max of the components exist ... So the error should be raised in any way, only if you implement the constraint it would make sense to change anything there.

This comment has been minimized.

Copy link
Member Author

uvchik replied Feb 25, 2016

In my assembler I use the following function.

def linear_constraints(om, block):
        lc.add_two_inputs_io_relation(om, block)
        var.set_bounds(om, block, side="output")
        var.set_bounds(om, block, side="input")
        lc.add_postheat_relation(om, block)

I do not need if-clauses within this function because the bounds for in_max will be set if in_max is defined and will be set to infinity if in_max is not set.

If they are set to infinity and I use the investment mode the error above is raised. This makes no sense because I do not need a constraint in_max + in_add < inf. Therefore the error is wrong and should be skipped. This is what my changes do, skipping the error if in_max is set to "inf" or is not set.

add HeatBus assembler
This is just a test and does not work.

@uvchik uvchik modified the milestones: March 2016 Release, February 2016 release Feb 26, 2016

Simon Hilpert and others added some commits Feb 27, 2016

@uvchik

This comment has been minimized.

Copy link
Member Author

uvchik commented Feb 29, 2016

I merged PR #107, so if I merge this branch the content of features/slack_components will be merged, too.

@uvchik

This comment has been minimized.

Copy link
Member

uvchik commented on oemof/core/network/entities/__init__.py in dd18861 Feb 29, 2016

We have to decide whether it is possible to use non-string uid's. Using tuples as uid was the idea of @gnn but the issue fixing that is still pending (see #26).

@simonhilpert : Your changes will not work with tuples.

@uvchik

This comment has been minimized.

Copy link
Member Author

uvchik commented Feb 29, 2016

All tests are okay, all examples work. Plausibility test look fine. I will merge this branch.

With this branch features/slack_components is merged without commit 0dceeb2.

@simonhilpert : To merge #107 you will have to rebase an solve the merge conflicts and the warnings.

uvchik added a commit that referenced this pull request Feb 29, 2016

Merge pull request #97 from oemof/features/heatstorage_with_dT
Transformer which raises the temperature

@uvchik uvchik merged commit 3519b00 into dev Feb 29, 2016

@uvchik uvchik deleted the features/heatstorage_with_dT branch Mar 2, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment