HomeUpSearchMail
NEW

Actions to be done

Actions to be done by Victor Reijs is licensed under CC BY-NC-SA 4.0

Actions

This are actions that are important to work on (these are puple bold texts in the below linked web pages).
Green texts are for VR's actions.
Black texts are for simulation (CFD/formula/etc.) interested people.
Red categories are important to me.

Categories of the actions:

1. To be checked during the present SlimmeMolen prototype
2. For possible integration in future SlimmeMolen prototype
3. Problems with software
4. More theory/literature needed
5. Possible new definitions
6. Include in future simulations
7. Better 3D-modeling sofware
8. Decision taking
9. Greyed out: is being dealt with
   

• A: The amount of Bytes needs to be determined over the coming time. InflucDB looks to use a lot of supprting data (index files?), long term storage is now done using csv.
  
• A: Need to check the sensor (AS3935) during thunder storms. Hopefully in the coming autumn/winter weeks.
• B: It would be good to test the LMS303DLHC (which is used in the smartmolen project). Not planned for this prototype.
• B: Perhaps better to use the ESP-12F (or ESP32 variant?) for lower power usage, but it is not expected that this will be prototyped.
• B: LoRaWAN should be a better alternative then WiFi and/or ESP-Mesh. It is not expected that this will be prototyped.
• B: For this prototype the accuracy of acceleration and speed is ok-ish, but it is expected improvements (by calibrating) can be made
• C: Need to determine why the InfluxDB database grows fast. The first 55 days of InfluxDB data 4GByte and the last few 10 days around 100MByte/day/2mills, we need to compare this to the 4.5MByte of JSON messages that are generated with the Boxes/day/2mills; why is there a difference of a factor of 20!?
  InflucDB looks to use a lot of supprting data (index files?), long term storage is now done using csv.
• C: Does someone know a solution of the maximum message size of I²C? Please let me know. For now, I am splitting the I²C messages.A constant can be chnaged in a supporting file.
  
• C: This ESP-Mesh instability is still a major issue!!! A question has been asked on the painlessMesh GitHub site. A more stable package has been made, but still not very reliable. Perhaps using LoRaWAN (which is expected not to be tested with this prototype).

• D: De verhouding stam hoogte en boom grootte is voor volwassen bomen 1 op 1.  Maar er zullen meestal ook struiken (tot 6m) onder bomen, in een tuin, staan. Dit verdient nog aandacht.
• G: Cd is depending on velocity, so it would be good to be able to include (in SIMSCALE) velocity in f. SIMSCALE has put this in the Feature-Wish list.
  

• D: Turbulentie (Turbulent Kinetic Energy: TKE) is belangrijk, door bomen die aanwezig zijn rondom de locatie van de wieken.
• E: Meestal is de windsnelheid niet echt mooi horizontaal gelamineerd (bv door bomen) en ook is ze links en rechts van de askop verschillend. Op deze webpagina is daarom een aanvulling gedaan: "de gemiddelde windsnelheid op 1m boven de ¼ van horizontale wiekuiteinden".

• D: Is IDW a good methodology to determine the local wind speed, or is (C)K(S/D) better?
• D: This theoretical z_0t should be closer to the 0.39m, or not? So is my assumption wrong for this theoretical terrain?
• D: Incorporating the roof form can be important in a CFD (certainly for nearby buildings).
• F: In the next iteration: use a reference ABL (with a certain z₀) and then go to 60m and then get a new u_ref in ABL formula for the different z₀. In the below: Only the z₀ was changed and not the u_ref.
  
• F: In the next iteration this opening between trees at 280deg will be rectified.
• G: The STL file made by SketchUp has problems. Advised to use STEP or Parasolid. Onshape could be used.

• D: This lower ABL at inlet Flow Volume needs to be investigated/understood to make a proper comparison.
• E: Welke gebouwen: alle binnen de 400m straal of alleen de meest invloedrijke(n). In STworkflow (3 meest invloedrijke); DHMworkflow (1 meest invloedrijke); VR workflow (alle gebouwen).
• E: Welke bomen: alle binnen de 400m straal of alleen de meest invloedrijke(n). In STworkflow (3 meest invloedrijke); DHMworkflow (1 meest invloedrijke); VR workflow (alle bomen).

VRExce

• D: The weighting of anemometer readings still needs some though.
• C: The raster package is slow, might be due to inefficient coding. Might try terra (of same authors)
• D: Explain unexplained differences in speedfactor between methods.
• E: So is K_n really an orthogonal knob (only depending on z_0m)?
• E: Is Effective Height coefficient same as Vertical momentum exchange (−u'w') value? I don't think so.
• D: aVR_abl needs to be verified theoretically.
• H: Which method is the best reference: CFD or local anemometer or ???
• H: It will be needed to understand the fine tuning of the knobs used for each method, this will allow a proper benchmarking.
• F: Would be good to have automatic house/tree determination from the DSM.

EmptyEFV

• G: Screenshots in SIMSCALE do not seem to be properly coloured!
• H: Is the found difference between k_s and equivalent z₀ significant?
• G: SIMSCALE's documentation also refers to the restriction y_p>k_s. But according to a source [pers. comm., Anon, 2025] it looks OpenFoam (SIMSCALE) is now able to overcome this restriction. SIMSCALE still has this restriction, perhpas y+ can be helpful. I am interested in a reference for that.

STWorkflow

• D: Benschop's method seems to work for meteorological stations, but don't know if this method also works for the mill region!

HouseSim

• D: Is this comparison/evaluation between Nägeli and simulation correct?
• D: After a house: Some kind of compression towards the ground or increase of Turbulent Kinetic Energy (TKE below is of the House with wind along saddle [z0=2m,]). Can this be explained?

RijnenLekSmartmolen

Acknowledgements

Disclaimer and Copyright
HomeUpSearchMail