standard type functions in pandapipes vs. pandapower

[dlohmeier]

I was trying to build some code implementing simple std_type functions for both pandapipes and pandapower, when I noted an incompatibility: standard types are saved in pandapower nets at the key "std_types", while in pandapipes it is "std_type". I was actually looking for an equivalent function of std_type_exists(net) in pandapipes.

I will open a pull request that adds this function. However, I would like to raise the question if it still makes sense to change the key in pandapipes to be the same as in pandapower.

[dlohmeier]

The PR is opened and I added quite a bunch of functionality and changed the std_type key. However, I realized that there are some errors in the implementation that make the functionality pandapipes.change_std_type not usable. In a typical std_type library, we store pipe std_types with the following entries:

std_type | nominal_width_mm | outer_diameter_mm | inner_diameter_mm | standard_dimension_ratio | material
80_GGG | 80 | 98.0 | 86.0 | 16.33 | GGG
100_GGG| 100 | 118.0 | 105.8 | 19.34 | GGG
125_GGG| 125 | 144.0 | 131.6 | 23.23 | GGG

However, in the pandapipes.create_pipe() function, we use the entry 'inner_diameter_mm' and convert it with a factor of 1/1000 to 'diameter_m'. If we now exchange the table entries with the std_type entries, nothing really happens, as none of the entries match, and even if, there would be a factor of 1000 between them.

My favorite option would be to do the following:

• rename the std_type entries
• change the diameter unit from m to mm
• maybe also check if we can drop some of the std_type entries, as there's quite a bunch that is never used within pandapipes (just optional).

[kbensafta]

Should this issue be considered as closed?

[dlohmeier]

Unfortunately, we still didn't implement the mentioned features and I think the discussion on how StdTypes should be defined (is a class a suitable definition type?) is continued...