search

bramvdh91 / modelica-ibpsa

Modelica libraries that are used and/or developed within IEA EBC Annex 60
0 stars 0 forks source link

Pipe issue31 data #62

Closed bramvdh91 closed 7 years ago

bramvdh91 commented 7 years ago

Putting pipe parameters (except depth and length) in separate record, drop-down menu with different standard pipes (adaptable for special cases). All validation models should be working.

bramvdh91 commented 7 years ago

@marcusfuchs @carlesRT Could you have a look at these changes? It's not necessary to merge immediately, but I think this would make it easier for users to build their own network.

bramvdh91 commented 7 years ago

@marcusfuchs maybe this is also relevant regarding our discussion about pipe data during today's TelCo?

bramvdh91 commented 7 years ago

I'm having a look at the merge conflicts now

carlesRT commented 7 years ago

I just pushed some changes in the branch issue264_pipe, you might have again some conflicts. I had a quick look and so far I would suggest to propagate dp_nominal as well as R of the pipe model PipeHEatLossMod.

marcusfuchs commented 7 years ago

When loading this branch, I get the following error message:

Error: Error: attempted redefinition of TimeDelay was ignored
File: D:/Repos/modelica-annex60/Annex60/Experimental/Pipe/Examples/TimeDelay.mo, line 2
Using old definition from:
In file: D:/Repos/modelica-annex60/Annex60/Experimental/Pipe/Examples/TimeDelay
bramvdh91 commented 7 years ago

@marcusfuchs could you check if this is solved by 3816025ea6c3f7ef16bb0b12fc89ec662e8d5ec9?

marcusfuchs commented 7 years ago

@bramvdh91 Thanks, yes, that solved the error for me.

Regarding the proposed changes, I think this is a very user friendly way of setting up the pipe model, which improves handling of the model for human users. Yet, for automated model generation, I would prefer to still have the option of setting all the values in the pipe without the complication of records. Could we implement a layered approach where we have the core similiar to the previous pipe implementation and have your new approach as a wrapper around the core pipe, parametrizing the model from records? In this way, users would have all advantages of the new approach, while auto-generated code can still directly tap into all parameters of the core model.

bramvdh91 commented 7 years ago

@marcusfuchs Okay, then let's keep this on hold for now while we tackle more urgent issues :) I can try to have a look at the wrapper model when I have a bit more time.