Temperatursummen in der Imkerei

Danke für die tollen Vorschläge. Auch wenn wir alle schon sehnsüchtig auf InfluxDB 2.0 und Flux warten und es so bald wie möglich ausprobieren wollen, will ich hier auch noch auf den weiteren potentiellen Kandidaten TimescaleDB hinweisen, den wir ebenfalls ins Auge gefasst hatten, weil diese Datenbank u.U. ebenfalls einige Probleme lösen könnte, die wir derzeit so bei der Datenverwaltung haben.

Wenn der aufgemotzte PostgreSQL die von Euch gewünschten arithmetischen Dinge gut beherrscht, könnten wir so Meß- und Metadaten in der selben Datenbank verwalten - das hört sich erst einmal nicht unpraktisch an ;].


Gefällt mir, ich hoffe wir können das für die kommende Saison realisieren.

OK, dann warten wir mal was die neue Version so bringt. Wenn man über die letzten 20 Tage aufsummieren könnte hätte man schon einmal die aktuelle #brutzellen. Für die Anzahl Bienen müsste man im prinzip immer nur die Mortalität multiplizieren und die schon berechnete Legerate addieren (Bienen*0,975 + legerate(-20d)).

Auch wenn ich das noch nicht in Excel modelliert habe könnte ich mir vorstellen, daß das Modell intrinsisch robust ist und es keine Grenzbedingungen braucht. Im Winter wird die Legerate automatisch niedrig, es sollte sich also eine Population auf niedrigem Niveau einstellen (ich tippe mal, daß diese etwas unterschätzt, da die Mortalität für Winterbienen zu hoch angesetzt ist). Unter Null geht das ganze aber ja nie und auch die Legerate wird mit der Formel nie Null, wodurch immer Bienen vorhanden sind. Im Frühling müssten sich dann von alleine die gewünschten Werte einstellen, die auch realistischer sind. Dann wird das Verhältnis Bienen/Brut ggf. aussagekräftig. Natürlich sind hier keine Trachtlimitierungen, Milbenschäden, etc. drin. Aber im Grunde geht es ja auch nur darum, daß die Werte von April bis Juni einigermaßen realistisch sind, wenn Schwärme fallen könnten und da sollte immer Tracht vorhanden sein (außer man steht im Raps) und Milben sind hoffentlich noch nicht kritisch.

Die Temperatursummen-Theorie bedeutet am Ende ja, dass die Volksgröße, sagen wir mal zu Beginn der Schwarmsaison, nur von der Startgröße der Population im Januar, d.h. bei Brutbeginn nach der brutfreien Zeit und den Temperatursummen abhängt.

Bienen fangen nach der Winterphase, die normalerweise brutfrei ist, Ende Januar an zu brüten. Auch da wäre spannend, wie sie den Zeitpunkt bestimmen, Vermutlich merken sie, dass die Tage länger werden und nehmen dann – unabhängig von der Außentemperatur – das Brutgeschäft auf. Aber auch das ist nur ein Faktor, die absolute Außen-Temperatur spielt auch eine Rolle und kann zu einem früheren Beginn führen, Kollegen berichten z.B. schon jetzt zu Hl. Dreikönig von Brut in den Völkern! Mit dem milden Winter gibt es also auch frühere Startpunkte. Für die Bienen ist das natürlich eine Wette auf Leben und Tod, wenn es gut geht, d.h. das Futter reicht und sich auch kein Futterabriss einstellt – weil es doch mal noch kälter wird und die Bienen auf der Brut sitzen bleiben und sie wärmen und dann nicht zum “Treibstoff” nebenan kommen und so auf gut vollen Waben verhungern – haben sie einen Entwicklungsvorsprung von anderen Vökern, die erst später mit dem Brutgeschäfft anfangen. Wenn das Futter nicht reicht, weil sie gegen zu viel Kälte heizen müssen oder sie nicht ans Futter kommen kann es auch den Tod des Volks bedeuten.

Der Brutbeginn ist also ein wichtiger Faktor, damit hängt dann auch wieder die Varroavermehrung zusammen, der Futterverbrauch, die Futterversorgung von außen. D.h. für die erste Aufwärtsentwicklung können neben den Temperatursummen noch andere gravierende Faktoren dazukommen.

1 Like

Bleibt noch die Frage ob dank Klimawandel der Brutbeginn überhaupt noch so relevant ist - zumindest meine Bienen brüten bisher mehr oder minder durch. Es soll ja auch Imker geben die den Bienen “etwas gutes tun” und sie in Italien überwintern, was die Winterpause auch deutlich verkürzen düfte. In den Tropen gibt es eh keine wirkliche Brutpause. Brutbeginn erfordert typischerweise Pollen (so die klassische Denkweise) und den gibt es hier meist mit der Blüte der Salweide, deswegen ist es sicher auch spannend die Blühphasen in Dashboard zu haben.

Habe mal etwas mit dem Modell gespielt für zwei extreme (wobei dann doch wieder recht ähnliche Standorte) List auf Sylt und Oberstdorf (die nördlichste und südlichste DWD Station). Hier erst mal die Brutzellen und die Zahl der Bienen über die letzten beiden Jahre:

Entwicklung

Und dann das Verhältnis von Brut zu Bienen:

Verh%C3%A4ltnis

Hier sieht man, erst mal, daß das Modell natürlich im ersten Monat nicht brauchbar ist (Anfangswert für Bienen war 0). Es fällt auf, daß eigentlich nie Schwarmstimmung einsetzt (Sterblichkeit zu klein?) und im zweiten Jahr in Oberstdorf die Brut früher beginnt - da war es letztes Jahr offenbar Anfang März mal zwei Wochen kurz recht warm.

Eine Schwäche ist sicher auch, daß hier alle Bienen berücksichtigt werden. An anderer Stelle habe ich aber einmal gelesen, daß es vor allem die Ammenbienen sind und gerade bei einer Massentracht wird im Volk eben auch schnell einmal umgeschult, damit mehr zum sammeln raus können (siehe Seeley).

3 Likes

Nachtrag: Eigentlich müsste man mit den Daten die wir ohnehin schon haben auch die Sammelbienen abschätzen können

  • Gewichtsverlust am morgen / Gewicht einer Biene
  • Honigeintrag über den Tag / (Honigblase * Sammelflüge/Tag)

Falls jemand einen der Lichtchranken-Bienenzähler an seiner Beute hat könnte man das sogar einmal validieren - dann reicht es schon fast für ein halbes Paper.

Korrekt! Siehe auch die Beschreibung der shift() Funktion als Bestandteil der neuen Anfragesprache Flux.

Examples

Shift forward in time

from(bucket: "hotzenplotz")
	|> range(start: -5m)
	|> shift(shift: 12h)

Shift backward in time

from(bucket: "hotzenplotz")
	|> range(start: -5m)
	|> shift(shift: -12h)
1 Like

Wird leider nicht so einfach sein, da ja während die “Spätaufsteher” erst ausfliegen, die ersten frühen schon wieder reinkommen. Wir wissen nur, wann die Bienen anfangen auszufliegen, da gibt es eine Gewichtssenke in der Grafik. Dann kommen wieder Bienen mit Nektar rein, es fliegen aber auch wieder wlche aus. Wie viel eine Biene tatsächlich einträgt hängt auch von der Flugstrecke ab, wenn sie weit weg muss ist der Eintrag weniger, da sie auch Futter für den Flug braucht. Daher werden wir die Ausflüge / Sammlerinnen nicht alleine mit dem Honigblaseninhalt errechnen können. Auch beim Nektar gibt es Unterschiede in der Zusammensetzung, vielleicht bekommen auch die Sammlerinnen wenig und kehren mit halbvoller Honiglbase zurück. In der Zwischenzeit trocknen die Bienen auch wieder den Nektar, d.h. am Abend ist weniger da als absolut gesehen eingetragen wurde.

Habe ich, liegt als Prototyp schon Jahre im Schrank. ;-)s

Was davon hast Du im Schrank: den Zähler oder das paper?! ;p

Den bee counter! ;-) fürs Paper hab ich deswegen noch keine Daten.

Zusammenstellung einiger öffentlicher Quellen für offizielle fortlaufend aktualisierte Grünlandtemperatursummen für Deutschland

ISIP

Übersicht und Auswahl::

https://www.isip.de/coremedia/generator/isip/Kulturen/Gruenland/GruenlandTempSum/Land.html

direkt: Baden-Württemberg, Bayern, Brandenburg, Hessen, Mecklenburg-Vorpommern, Niedersachsen, Nordrhein-Westfalen, Rheinland-Pfalz und Saarland, Sachsen, Sachsen-Anhalt

Für Schleswig-Holstein und Thüringen sowie die Stadtstaaten sind keine Messungen ausgewiesen, zumindest für die letzteren sind aber in deren Randregionen representative Stationen der angrenzenden Bundesländer zu finden.


DLR RLP

Über die Dienstleistungszentren Ländlicher Raum Rheinland-Pfalz (DLR RLP) lassen sich die GTS für die Stationen folgender Bundesländer finden:

Baden-Württemberg, Bayern, Rheinland-Pfalz und Thüringen


Die Werte der identischen Stationen zwischen ISIP und DLR RLP sind gleich (kaum verwunderlich), der Voraussagezeitraum ist aber bei letzteren vier Tage länger. Bei DLR RLP sind außerdem noch die historischen Werte ab 1994 an gleicher Stelle abrufbar.

1 Like

Beispiel für die Darstellung von Grünlandtemperatursummen (GTS) in Grafana

Abbildung für Januar: 0,5 * (positive Tagestemperatur-Mittelwerte)

Die beispielhafte Darstellung ist geringfügig zu optimistisch, da u.a. der Startwert nicht richtig in die Kalkulation genommen wird / werden kann in IFQL. Umsetzung auf FLUX ist noch in Arbeit.

2 Likes

Eine erste Umsetzung in Flux ist für die DWD-Daten fertig: Ein Query, der aus drei einzelnen Queries für die jeweils anders gewichteten Zeiträume besteht, die resultierenden Tabellen mittels union() in einer zusammenfasst und diese dann als Tageswerte yield()et sowie ne akkumulierte Summe rauswirft:

jan = from(bucket: "dwd_cdc")
  |> range(start:2019-01-01T00:00:00Z, stop: 2019-01-31T23:59:59Z)
  |> filter(fn: (r) =>
      r._measurement == "dwd_cdc_temp_2m_c" and
      r._field == "value" and
      r.sta_name == "$COMMON_CDC_NAME" and
      r.quality_level == "2" and
      r.produkt == "10_minutes"
     )
  |> aggregateWindow(every: 1d, fn: mean)
  |> keep(columns: ["_value", "_time"])
  |> filter(fn: (r) => r._value > 0)
  |> map(fn: (r) => ({
    _time: r._time,
    _value: r._value * 0.5
    }))
  
feb = from(bucket: "dwd_cdc")
  |> range(start:2019-02-01T00:00:00Z, stop: 2019-02-28T23:59:59Z)
  |> filter(fn: (r) =>
      r._measurement == "dwd_cdc_temp_2m_c" and
      r._field == "value" and
      r.sta_name == "$COMMON_CDC_NAME" and
      r.quality_level == "2" and
      r.produkt == "10_minutes"
     )
  |> aggregateWindow(every: 1d, fn: mean)
  |> keep(columns: ["_value", "_time"])
  |> filter(fn: (r) => r._value > 0)
  |> map(fn: (r) => ({
    _time: r._time,
    _value: r._value * 0.75
    }))
  
rest = from(bucket: "dwd_cdc")
  |> range(start:2019-03-01T00:00:00Z, stop: 2019-12-31T23:59:59Z)
  |> filter(fn: (r) =>
      r._measurement == "dwd_cdc_temp_2m_c" and
      r._field == "value" and
      r.sta_name == "$COMMON_CDC_NAME" and
      r.quality_level == "2"  and
      r.produkt == "10_minutes"
     )
  |> aggregateWindow(every: 1d, fn: mean)
  |> keep(columns: ["_value", "_time"])
  |> filter(fn: (r) => r._value > 0)
  |> map(fn: (r) => ({
    _time: r._time,
    _value: r._value * 1.0
    }))
  
union(tables: [jan, feb, rest])
  |> sort(columns: ["_time"], desc: false)
  |> map(fn: (r) => ({
    _time: r._time,
    _value: r._value,
    foo: "Tag"
    }))
  |> yield(name: "bars")
  |> cumulativeSum(columns: ["_value"])
  |> map(fn: (r) => ({
    _time: r._time,
    _value: r._value,
    foo: "Total"
    }))

Oder auch zum Angucken als dediziertes Dashboard im DWD-Folder: Wetter: DWD / Grünlandtemperatursumme (GTS) und Kältesumme

Wo sich des mit den separaten Zeiträumen und Schwellwerten nun so schön in Flux abbilden lässt: Wünscht sich jemand noch andere, Pflanzen/Bienen/Einhörner-spezifische, Temperatursummen? [Da gibts ja noch ganz andere Rechenwege für andere Pflanzen. Edit: Damn, sind ist immernoch keine Exponenten berechenbar in Flux. Auch selbst eine Exponentialfunktion zu implementeren scheint mir bislang nicht trivial.]

2 Likes

Flux Abfragemonster here…

jan = from(bucket: "dwd_cdc")
    |> range(start:2019-01-01T00:00:00Z, stop: 2019-01-31T23:59:59Z)

    [...]

Saustark! Sieht nach ordentlich bewältigter Flux Lernkurve aus.


P.S.: Bei Gelegenheit muss ich mir von Euch mal erklären lassen, was Ihr da tut.

1 Like

You’ve asked for it, darling. Ick geh den Query mal Schritt für Schritt durch (wer nicht Flux lernen will, sollte hier vmtl. mit dem Lesen abbrechen.)

jan = from(bucket: "dwd_cdc")

Wir nehmen uns mal die “dwd_cdc”-Datenbank, aaaber tun das Ergebniss dieses ja noch weiter spezifizierten Queries in eine Art Variable und nennen sie “jan”.

  |> range(start:2019-01-01T00:00:00Z, stop: 2019-01-31T23:59:59Z)

Joar, hier würde mensch sonst[tm] “$range” in die Klammern schreiben: Eine Variable, die Grafana anhand des aktuell gewählten Zeitfensters Flux-gerecht bereitstellt. Aber wir wollen ja mal nur den Januar betrachten. Unsere DB denkt in UTC, der DWD auch: Schick.

  |> filter(fn: (r) =>
      r._measurement == "dwd_cdc_temp_2m_c" and
      r._field == "value" and
      r.sta_name == "$COMMON_CDC_NAME" and
      r.quality_level == "2" and
      r.produkt == "10_minutes"
     )

Lasst uns unsere Datenbank filtern! “r” definieren wir als unsere response. “interne” Variablen beginnen mit nem Undersore; das ist für _measurement, _field und _value gegeben. Übrige/individuelle tags werden ohne
_ angegeben. Der Wert aus der Variable $CDC_COMMON_NAME stellt das Grafana über unser Station-Dropdown bereit (hier könnte auch nen Stationsname “hardcodet” stehen).

  |> aggregateWindow(every: 1d, fn: mean)

Ist ne Helper-Function, die eigentlich erstmal window() aufruft, und denn die einzelnen Series wieder group()t. Damit lassen sich auch verschiedene Messrhytmen “normalisieren” und vergleichen. In diesem Fall machen wir aus unseren “alle 10min-Daten” die gewünschten Tagesmittelwerte.

  |> keep(columns: ["_value", "_time"])

Lasst uns unnötiges Wegschmeißen.

  |> filter(fn: (r) => r._value > 0)

Ah, wir interessieren uns ja nur für Tagesmittelwerte über 0°C! Also filtern wir mal auf die. Das macht ja auch jetzt erst Sinn, weil wir vorher noch nicht auf Tagesmittelwerte aggregiert haben.

  |> map(fn: (r) => ({
    _time: r._time,
    _value: r._value * 0.5
    }))

Tja, dann müssen wa noch unseren Wert gewichten. Ist ja Januar, also mit 0.5. _time muss mit aufgerufen werden, damits überlebt.

Ok, dasselbe für

feb = from(bucket: "dwd_cdc")

und analog für

rest = from(bucket: "dwd_cdc")

Jetz dieses union():

union(tables: [jan, feb, rest])
  |> sort(columns: ["_time"], desc: false)

Sortierung ist wichtig, sonst kommt etwa der 1.-11. Februar zuerst in die Tabelle und dananch erst der 1.-31. Januar und das arme Grafana ist sehr verwirrt und malt plötzlich Kreise. (Srsly. Grafana supports time-travel!)

  |> map(fn: (r) => ({
    _time: r._time,
    _value: r._value,
    foo: "GTS Tag"
    }))

Boar, diese Beschriften von einzelnen Datenserien ist die Hölle mit Grafana & Flux. Hier fügen wir an jeden Messwert noch nen key-value-Päarchen, damit wir die Serie als “Tag”(eswert) wiedererkennen können.

  |> yield(name: "bars")

Weil wir hier grafisch Balken nehmen, heissts “bars” und es wird die Series an genau dieser Stelle per yield() “vermeldet”, also als separate result-Tabelle ausgeworfen und gemalt, ehe wir sie weiter modizifieren. Somit haben wir jetz erstmal alle gewichteten Tagesmittelwerte > 0°C im Bild.

  |> cumulativeSum(columns: ["_value"])

Wir wollen aber auch die kummulierte Summe aller Werte! (Bei single stats: Nur sum() )

  |> map(fn: (r) => ({
    _time: r._time,
    _value: r._value,
    foo: "GTS Total"
    }))

Also benennen wir unser lustiges Feld nochmal um und brauchen es nicht nochmal yield(en), weil wir jetzt ja am Ende sind und damit eh unsere/(die) eine Ergebnistabelle rendern.

3 Likes

Sorry for the buzz, aber wir können jetzt auch die Grünlandtemperatur-Berechnung mit der 10-Tage-Vorhersage weiterführen und dies auch auf die Kältesumme anwenden. Gibts nun in einem einzelnen Panel integriert im Referenz-Dashboard für die Grünlandtemperatursumme, funktioniert auch für Bremen (und auch für den Brocken, wenns etwas kälter sein darf):

(Standbild des dashboards)

:dancer: … ja, das sind dann auch nur im positiven je Zeitraum drei und für die Vorhersage je nochmal 3x2 = 6 Teilabfragen in einen Query (Kältesumme läuft separat). [Edit: Ein Glück müssen wa nun nicht mehr für die zwei Darstellungen (je Tag vs. akkumulierten Gesamtwert) noch einen Satz Queries fahren. :]

[Edit: Was die Populations-Abschätzung anbelangt muss ich leider feststellen, dass Flux zwar viel mehr tolles Neues kann, aber auch noch einige Grundlagen noch nicht. Zu diesen gehört leider leider auch noch das Rechnen mit Exponenten. :roll_eyes:]

3 Likes

english tl;dr
FLUX 0.12.0 (as deployed on swarm.hiveeyes) is not yet capable of functions like pow(), logx() or even sqrt(). Therefore to adopt the Bretschko (“Heuvel”) formula for oviposition rate, it should be substituted with a Taylor 3rd order polynome.


Aber wir haben *, /, - und + … was braucht es mehr! ;)

Um den Exponenten wegzubekommen, paßt ein Taylor-Polynom (hier ohne Restglied). Eine Polynom dritter Ordnung wurde gewählt, da die Annäherung als zunächst ausreichend angesehen wird. Dafür braucht es vier zuvor ausgerechnete Koeffizienten an einem Bezugswert x0. Hier wird als x0 = 10°C genommen, da das Polynom im interessierenden Wertebereich von 1°C bis 25°C mit den Koeffizienten von 10°C am besten “paßt”.

Mein eigenes Taylor-Reihen-Wissen reichte nicht mehr ganz, so daß dank @bty seit gestern also ein Näherungs-Polynom existiert, das man in FLUX verwenden könnte:

Formeln und kleine Herleitung

FIXME: also notate in mathjax

Der Term 22,8295*x^1,4254 (die Eiablagerate nach Bretschko, Bergmann…) hier vereinfacht “Heuvel-Formel” genannt) muß durch eine sinnvolle Näherung ohne Potenz ersetzt werden. x ist die Tageshöchsttemperatur.

f(x) = 22,8295 * x^1,4254
a = 22,8295
b = 1,4254
f(x) = a * x^b

Die gleich benötigten ersten drei Ableitungen dieser Funktion lauten:

f'(x) = a*b*x^(b-1)
f''(x) = a*b*(b-1)*x^(b-2)
f'''(x) = a*b*(b-1)*(b-2)*x^(b-3)

Taylor-Polynom 3. Ordnung hierfür:

T f(x) = f(x0)+f'(x0)*(x-x0) + f''(x0)/2 *(x-x0)*(x-x0) + f'''(x0)/6 * (x-x0) * (x-x0) * (x-x0)

Um damit nun rechnen zu können, werden

  • der Funktionswert (spätere Koeffizienten) für den Wert x0 berechnet, sowie die ersten drei Ableitungen an x0.

  • für x0 = 10°C ergeben sich:

    f(x0) = 607,989949
    f’(x0) = 86,662887
    f’‘(x0) = 3,686639
    f’‘’(x0) = -0,211834

  • dann wird eingesetzt (das wäre auch der Term, der im FLUX-query steht, solange es kein POW() gibt; die zwei Divisionen dort kann man da noch ‘kürzen’ und natürlich zu Konstanten machen, auch könnten (max(temp) -10) sowie dessen mehrfache Multiplikationen einen Schritt vorher natürlich auch Variablen zugewiesen werden), :

607,989949 + 86,662887*(max(temp) -10) + 3,686639/2 * (max(temp) -10) * (max(temp) -10) + -0,211834/6 * (max(temp) -10) * (max(temp) -10) * (max(temp) -10) 
Tagesmax. Eier/d; “Heuvel” Eier/d; Taylor-Poly 3.Ordn.
1°C 23 3
2°C 61 51
3°C 109 104
4°C 165 162
5°C 226 225
6°C 294 293
7°C 366 366
8°C 442 442
9°C 523 523
10°C 608 608
11°C 696 696
12°C 788 788
13°C 884 884
14°C 982 982
15°C 1084 1083
16°C 1188 1187
17°C 1295 1293
18°C 1405 1401
19°C 1518 1512
20°C 1633 1624
21°C 1751 1737
22°C 1871 1852
23°C 1993 1969
24°C 2118 2086
25°C 2245 2204


Dann fehlen noch

  • der Stärke des Überwinterungsvolkes (Konstante bzw. dashboard-ad-hoc-Variable),

  • die Mortalitätsrate (einfaches lineares Glied),

  • und die auflaufende Brut, die cumulativeSum der Formel oben ab 21 Tage nach Beginn (1.2. oder ab nachgewiesenener Brut)

Vielleicht brauchen wir für letzteres gar kein time shift, aber das soll @wtf entscheiden! ;)

2 Likes

Yeah. Hab das mal etwas umgeknetet, zur Ermittlung das Temperatur-Tagesmaxima zugrunde gelegt und ruf erstmal nur den Zeitraum 1.2. bis 31.12.2019 auf, soweit erstmal in meinem Sandkasten-Dashboard zu finden: :nerd_face: Labor / Eiablage & geschlüpfte Bienen nach Heuvel (2019). Die referenzierte DWD-Station ist dort einstellbar.

(Standbild des dashboards)

Bitte schaut mal jemand vom Fachlichen drauf ob das grob Sinn ergibt. (Ne Vorhersage klebt da auch dran; der “Knick” in einigen Stationen sieht erstmal aus wie nen Rechenfehler in der Vorhersage, aber bspw. Berlin hatte gestern & heute (!) 15-16°C, vgl. Hamburg für “ohne Knick”.)

Wenn des stimmig erscheint stünde wohl an als nächstes mit der Mortalitätsrate noch ne Kurve “Brut” zu bauen, am Besten um 20 Tage versetzt, wenn ich @mde’s Beitrag nochmal studiere.

2 Likes

Hmmm, bei der maximal en Eianzahl pro Tag streiten sich die Gelehrten, früher waren es mal 1500, dann das 2-fache Körpergewicht, nun hört man 2000 oder das 6-fache Gewicht. Wie auch immer, jedenfalls ist das das Maximum im Mai / Juni! Wenn wir da an einem warmen Tag jetzt schon mit 1000 Eiern rankommen macht mich das stutzig, die müssen nicht nur gelegt werden, sondern auch gepflegt und gefüttert werden, und dass es dann – am nächten Tag – auf 150 runter geht kann ich mir auch nicht vorstellen. Befürchte so dynamisch ist dass System Bienenvolk dann doch nicht. Aber nur ein leichter Zweifel ohne Zahlen die das widerlegen im Hintergrund …

Danke @wtf - gefällt mir wieder einmal sehr gut! :)

Nein - denn die hast Du ja bereits mit der orange-farbigen Kurve gebaut , yeah! 8)

  • Als zweite Kurve braucht es die “Gesamtzahl Bienen”, die startet per fixem Wert am besten als einstellbare Variable ab Tag 1. (10000 wäre ein sinnvoller default)

  • ab dem zweiten Tag wird diese Gesamtzahl jeden Tag mit 0,975 multipliziert - die Mortalität.

  • die auflaufende Brut findet in beiden Kurven Eingang: 20 Tage nach Eiablage (am 21. Tag des Ei) verschwindet diese Anzahl von “Brut” und wird “Anzahl Bienen” zugeschlagen (welche mit 0,975 multipliziert wird, s. o.).

  • darüber hinaus interessiert das Verhältnis Brut zu Bienen: ab >= 90% Brut/Bienen möchte man das markiert sehen (paßt daher als gauge und anderes panel).

Wenn das fertig ist, wollen wir noch den Anteil verdeckelter Brut an Gesamt-Brut sehen, aber dazu später … ;)

1 Like

zur erläuterung der zusammenhänge im bienenvolk beginne ich hier eine literatursammlung zum thema:

  • josef bretschko - naturgemäße bienenzucht
    hab ich in meinem archiv, bei interesse geb ich den link weiter.
  • ferdinand gerstung - das grundgesetz der brut- und volksentwicklung
    pdf, 14Mb hier
  • ludwig armbruster - imkerbetriebslehre der erzeugnung
    html hier
2 Likes