opensimhub / openhpl Goto Github PK

There have been major updates to the naming conventions in the 2.0.0 release of OpenHPL. As usual, there was not enough time to also recreate the User's Guide document. So this is a leftover from #9.

One idea would actually be to convert the User's Guide from an external document to add it to the internal ´OpenHPL.UsersGuide`.

Here:

there are many references to undefined connectors:

Error: OpenHPL.Tests.HPElasticKPPenstockCompres [23:3-23:3] Unknown identifier reservoir.n.
Error: OpenHPL.Tests.HPElasticKPPenstockCompres [22:3-22:3] Unknown identifier intake.n.
Error: OpenHPL.Tests.HPElasticKPPenstockCompres [21:3-21:3] Unknown identifier surgeTank.n.
Error: OpenHPL.Tests.HPElasticKPPenstockCompres [20:3-20:3] Unknown identifier penstockKP.n.
Error: OpenHPL.Tests.HPElasticKPPenstockCompres [19:3-19:3] Unknown identifier turbine.n.
Error: OpenHPL.Tests.HPElasticKPPenstockCompres [18:3-18:3] Unknown identifier discharge.n.
Error: OpenHPL.Tests.HPElasticKPPenstockCompres [16:3-16:3] Unknown identifier aggregate.P_in.
Error: OpenHPL.Tests.HPElasticKPPenstockCompres [15:3-15:3] Unknown identifier aggregate.u.

Many other models in OpenHPL.Tests seem to have the same/similar issue.

The industry standard IEC60193 contains formulas for determining graviation, density, atmospheric pressure, vapour pressure etc.
(inkl. default values).

Having a valve model would make it more obvious to create simple waterway models without the need for turbines. Though currently the general Turbine model is nothing else than a valve with some signals connected to it "to get rid" of the used energy.

Now a valve model could then be extended to become what the current Turbine model represents.

They will fail when checked on their own. But work when connected. So something is missing here.

The component OpenHPL.Waterway.Fitting allows to set the fitting type to either "Reduction" or "Expansion" in addition to be able to define the two different diameters. This basically means that one can for example define an expansion for a diameter that becomes smaller.
This should be improved and the expansion and reduction type should be automatically determined based on the given diameters.

This is a follow-up from #21. It would be nice to have a better quality image for the explanation of the KP method currently stored in besad.png:

The coding convention for Descriptive Strings is that it should start with UpperCase, for example, parameter Modelica.SIunits.Height H = 120 "vertical component of the length of the surge shaft" needs to be replaced with parameter Modelica.SIunits.Height H = 120 "Vertical component of the length of the surge shaft" .
Also, the commenting style of using //// should be improved with // for single line and /* (multiline comment)*/ .

The documentation and parameters always refer to inlet and outlet but also to D_1 and D_2. In addition the connectors are named p and n which adds even more confusion.
The naming should be cleaned up and should use index i and o instead, throughout the library.

The way the pressure drop is calculated in the turbine model OpenHPL.ElectroMech.Turbines.Turbine thee turbine control signal u_t is part of the denominator causing a "division by zero" error if the input signal is 0.

Please check the OpenModelica test report on the library. There are 21 models failing during the simulation stage because of errors of this kind

Not possible to open file "C:/Users/liubomyr/OneDrive/Documents/PhD/HydroCord/Servo_pos.txt":
No such file or directory

I would suggest to retrieve those files from Liubomyr's OneDrive account, put them under the Resources directory of the library, and access them via the modelica:// URI and loadFile utility function.

PNG images should ideally be replaced by SVG images. That way we don't have to maintain 2 versions of the same image.

• besad.png
• darcyf.png
• darcyf_zoomed.png
• ghosts.png
• kp.png
• penstock.png
• pipe.png
• SharpOrificeSurgeTank.png
• simplegen.png
• surgepic.png
• ThrottleValveSurgeTank.png
• turbinepic.png

@pandeysudan27 could you see if you can get hold of pdfs that can be converted to SVGs or recreate them if not possible?

The library contains a set of global parameters that are defined in the model "Contants" and need to be instantiated for all models under the name "Const". Now the naming is rather unfortunate since we are talking about (mainly) parameters and not constants. So the name should reflect this. I propose to change the name to Parameters and instances getting the default name para.

Suggest to merge/consolidate TurbineContact2 and TurbineContacts2

Add an implementation of elastic pipe (electircal analoge, similar to SIMSEN).

There seems to be some issues with the Fitting implementation.

One obvious one seems to be the wrong formula for area calculation in
https://github.com/simulatino/OpenHPL/blob/6cbf8a63777fc5726d4c36689676cb4a86b52f0b/OpenHPL/Waterway/Fitting.mo#L20
where the "^2" is missing. Do you agree @liubomyrv ?
Also the output of the phi functions needs to be investigated as the function returns not the expected values.

Trying to run the example (HPSimple_Francis_GridGen) causes a crash.

After some digging around it seems to be due to the initial powerflow data in the order2 generator.
The values appear to be in Watts, but the fields take values that are in MW as illustrated in the image below.

Reducing these values to 16 and 11 respectively seems to solve the problem.

@boerrebj: Abstract classes (partial classes in Modelica terminology) are useful for collecting common parts of multiple detailed models. As
an example,

• AbstractPipe basis class for both rigid water column pipe as well as elastic
  water pipe
• AbstractValve basis class for different types of valves
• AbstractTurbine basis class for different turbine types

Please check the OpenModelica old frontend test report on the library. There are many models failing during the code generation phase. I understand the library was developed using OpenModelica/OMEdit, so those models should in principle work.

Maybe they were broken during the library development and left like that because of lack of maintenance and proper CI monitoring. I would suggest to check them out thoroughly and either fix them or remove them from the library.

It would be nice to have model of a pump turbine.