[News] EDuWaFa - Energie Durch WAsserFAll (high pressure)

OSEG Projekte Projektinkubator ("PROTO")
1

– Wiki –

Repository


All below may be discussion or outdated information.



Energiegewinnung Wasser - Übersicht:

Energie durch Wasserbewegung oder korrekter durch Impuls (=momentum in English) (EDUWASI)

  1. vertical:
  • EDuWaFa (WAterFAll - High head/pressure, low volume, high speed hydro power plant)
  • EDuWaMa (WAterMAsses - High volume, low head, low speed hydro power plant)
  1. horizontal (no direct gravity component, indirectly there is because gravity drives a stream downward and drives tides):
  • EDuWaFl (WAterFLow - Waterwheel (Wasserrad) z.B. HydroCat, wenn dann schon mobil)
  • EDuWaTi (WAterTIdes - Tides hydro power plant)
  1. circular:
  • EDuWaTu (-"- WAterTUrbulencies)
  • EDuWaRo (-"- WAterROtation)

Gibt es neben horizontal planar, vertical planar und circular (Vortex, Wirbel) weitere Typten?


Leitspruch:
Entwicklungsentscheidungen lassen oft bitteren Streit in Open source Projekten entflammen (siehe z.B. KiCAD), deshalb schon hier ein Leitspruch nachdem sich alle Entscheidungen richten:
For the goals we bake, the best and simplest solutions we take.
Note: Since simplicity in most cases implies low-cost, that is not explicitely stated. By using plural this also implies that we will not stick with one solution and are open to multiple solutions in several project branches. All is kept under a versioning system. Common files desirably are put in the highest level folder that is still under versioning. (So there is no extra ‚common‘ folder - instead the highest project level automatically is common to all branches without naming it anywhere.)

For sake of equality, we could even abandon the word ‚branch‘ and even omit ‚trunk‘ and simply use category names. e.g. using pattern $PROJECT_DIRECTORY/<ordering_using_three_digits*_if_desired>--<how_it_s_done1>/<ordering_3digits*>--<how_it_s_done>/.
*3digits because this way it’s easy to insert another entry/module inbetween some two other modules at all times.
There are two possibilites:

  1. Every folder in the highest level of the project file structure is an individual ‚branch‘. (hence a clone, checkout of the trunk or how ever you call it) The trunk (main version) also is there but is not called trunk to not give the impression that all in there is settled and the other branches are not.
    OR
  2. We have only two repositories:
  • final/trunk where there is no -How:<how_it’s_done>/ addition to the folder names.
  • branch where there is all development and each folder can be checked out and committed separately. In this approach checkout and changes are more refined and thus there is less overhead. I think this is not worth it.
    OR
  1. We have only one repository and no branches. There we have one folder structure where we omit the ‚-How:<how_it’s_done>‘ and this is the current real world solution that is the most promising. It can be seen as a collection of the other folders/ideas that are most simplistic yet best, so still fulfill our requirements. The chosen development folders are linked into these main folders using GNU/UNIX (Linux) symbolic links.

The last approach is the most promising one for me as adapting a new and simpler solution that some developer has found is much easier because there is no merge involved at all. The most mature submodules can simply be linked in a wild mix as long as those sub/modules are disjuct and that mostly is the case.
This way even the review can be omitted and every new idea will simply get it’s own folder in which we note what is special about this solution (via the How:<how_it’s_done>/ in the folder name).

For not having giant downloads once the repository gets filled, we could give each kind (the different how-it-s-done) and link then only locally and once on the server. The server ‚best solution‘ (containing linked folders) must still not be used if one does not like to. One can always locally link differently.

Example for Possibility 3 (see list above):

  • Energy_Hydro_EDUWAFA/
    / \
  • 010-Power-How:nuclear_and_fuel_cells/
    • 010-Nuclear-How:Cold_fusion/ …
    • 010-Nuclear-How:Hot_fusion/ …
    • 020-Fuel_cell-How:only_using_water_as_electrolyt/ …
    • 020-Fuel_cell-How:I’m_convinced_this_is_simpler/ …
    • 010-Power-How:fuel_cells_only/
      • 010-Fuel_cell-How:air_cathode_choke/ …
    • 015-Gravity_wheel-added_this_inbetween_Power_and_Hull/
      • - no sub directories yet -
    • 020-Hull-How:I’m_convinced_this_interaction_of_electronics_and_mechanics_is_better/
      • 010-Mechanics-How:using_titanium_micro_meteor_shield/ …
    • 020-Hull-How:but_I’m_convinced_the_mechanics_don’t_need_to_have_those_electronics_hooks_if_we_glue_them_to_the_walls_instead/
      • 010-Mechanics-How:using_titanium_micro_meteor_shield/ …
      • 020-Electronics-How:never_using_bolts_instead_glue_all/ …
      • 020-Electronics-How:good_idea_but_no_I_prefer_keeping_thebolts_and_using_the_glue_additionally/ …

Entwicklungsentscheidungen - Beispiel:
As an example for how to come to a solution, for the question if we merge some patch or not, consider we want to achieve the following:
Our batteries must not break (e.g. catch fire). Implies: Have a reasonable long lifetime.
This goal is subsequently called a requirement interchangably.

So we chose long-life batteries (current state of the art is LiFePO4 which is heavily tested and used by the military and only recently bad light was shed on the batteries dues to Airbus battery problems).
We need batteries for full-filling peak energy demand (e.g. switching on strong electric motors where we require a lot of ‚invisible‘ power). If we omitted them, what is possible, we had to switch to grid-power whenever a high energy demand was required. In cases where there is an electric power grid available this is an option.

As these high-power-demand peaks don’t occur too often, a very small capacity battery will do - as a starting point we use 10 Ah for supplying 10A for one hour or 20A for half an hour (and so on). As we talk of three phase power what is usually required for farmers (and open source ecology needs to build farms for foraging any kind of food in an ecological way). So we talk of 700V DC batteries here. That means that roughly 20A * 410V = 8200 W peak power can be supplied for half an hour. If the water plant runs short of water or fails out of another reason, this of course probably is not enough time to repair the hydro power plant, but the best way to realize that something is wrong with the plant is that there is no more electricity anyway (unless some critical applications are running, so the 30 minutes give enough time to either deploy an emergency generator or get the job done or terminate the ciritcal electric machine in a soft way instead of the hard and sudden stop of electric energy supply.).

How?

  • Batteries must not be overcharged.
  • Batteries must not be drained fully empty.
  • Batteries must not be unbalanced. (Special for Lithium type batteries, on he other hand they don’t suffer from memory effect like Nickel batteries do and have a much longer mean lifetime.)
    Now to fulfill this we deployed a very strange and unconventional strategy and I know that people will complain about heavily. Nevertheless I will test this approach because it is the simplest yet best solution, because it still fulfills all the requirements for keeping the batteries healthy.

If now of course another developer makes another proposition this will immediately and automatically result in creating a branch for the developer’s idea. There are no people that have the power to stop this idea, we don’t have hierarchies (at least for projects that are under my command … ha, funny Antithetik … I meant those that I am part of).

Once the simplest solution so far fails, we immediately can exchange trunk and the next simple and promising branch. This way noone will be angry because some developer denies to give merge-permission in the patch merge-review. There are no patches that change the principle of how to do things unless they are simpler and still fulfill the requirements. Then the current solution gets into a new branch and developers that think this approach is most promising can still continue their efforts until they make the way back to trunk eventually by simplification and or breakthroughs that convince all the other developers.

It’s also good to discuss a new solution in a thread pior to implementing it as other developers could give some insights in how such a solution could be implemented (such to save the other developer some work and time).





EDUWAFA Ziel:

  • Elektrische Energieerzeugung: 2…20 kW (micro hydro).
    Der Prototyp konkret:
  • Dual Output: 1x 2 kW bei Niedrigwasser (Sommer) + 1x 4 kW sonst.
    Entwicklung:
    • [strike]Versionierungssystem für den Webspace[/strike] (done) (Server wäre viel einfacher, weil wir da ROOT, also Administrator, wären und damit alle benötigten Installationen leichter wären als Mercurial und Python und alle anderen benötigten Pakete ohne diese Rechte zu installieren.)
      Ziel dieses Unterfangens: Forenthema - Soll das Wiki Entwicklerseiten spiegeln?
    • BMS - BatterieManagementSystem (done in Revision 1, reference to be added, currently there are KiCAD problems for me).
    • Rohrleitung, bis dato wurde vergeblich nach gebrauchten und günstigen 10cm-Durchmesserrohren gesucht. Aber egal ob man Weinbauer fragte oder das Internet durchsuchte, immer gab es Probleme. Die ostdeutschen Länder waren zu weit entfernt oder die gefundenen Rohre hatten Bewässerungslöcher. Nach langem Hin- und Her also folgender ‚Trick‘: Wir nehmen einfach mehrere 5cm-Durchmesserrohre an Stelle des einen 10cm-Rohres.