[1.3.20] 2024-10-21

*Context*
- Texture mapping for sphere objects was not correct. The top cap was not being properly mapped, resulting in a dark spot.
- Added Context::listGlobalData() to list out all global data in the Context.
- There were still issues with tube twisting when using Context::appendTubeSegment() based on the implementation from v1.3.19. This should now be fixed.
- Modified helios vector types vec2, vec3, and vec4 normalize methods to also return the normalized vector. This allows for chaining of operations.

*Energy Balance*
- Added overloaded version of EnergyBalanceModel::addRadiationBand() to add multiple bands at the same time by passing a vector.

*Stomatal Conductance*
- Error in StomatalConductanceModel::setBMFCoefficientsFromLibrary(const std::string &species_name) function fixed.

*Plant Architecture*
- Added capability of having evergreen plants. This is controlled through PlantArchitecture::setPlantPhenologicalThresholds();
- Added olive, pistachio, and apple trees and grapevine (VSP) to the library.
- 'flower_arrangement_pattern' parameter of the internode has been removed. It currently now follows the phyllotaxy of the parent shoot.
- An error was corrected in which the first peduncle segment was being set to the internode color.
- An error was corrected that would cause inconsistent behavior of the shoot internode when there were multiple child shoots originating from the same node.
- Changed how girth scaling is handled. The shoot girth is now calculated based on the downstream leaf area. The new parameter is called "girth_area_factor", which is cm^2 branch area / m^2 downstream leaf area.
- The parameter 'flowers_per_rachis' was changed to be 'flowers_per_peduncle'.

*Radiation Model*
- When writing output images, the radiation model now checks to make sure the output directory exists and creates it if it does not.

*Synthetic Annotation*
- Error (Windows OS) fixed to use the filesystem library for file management instead of mkdir. Credit to Sean Banks for this edit.

*Weber-Penn Tree*
* Credit to Corentin LEROY for these edits
- Addition of variable range parameters for WeberPenn tree generation
- Addition of a sample project to demonstrate how one could build tree orchards based on a WeberPenn XML configuration

*Canopy Generator*
* Credit to Corentin LEROY for these edits
- Handling of parameters that were not parsed from a CanopyGenerator XML configuration for grapevine canopies
- A refactoring of the way canopy types are handled. Now all canopy classes inherit from BaseCanopyParameters, and all grapevine canopy classes inherit from BaseGrapeVineParameters. On top of that, parameters read from an XML file are stored so that canopies or individual plants can be built later on. This allows client code to have no knowledge at all about the types of canopies or plants that can be built; this information is exclusively written in the configuration file.
- Addition of variable range parameters for grapevine canopies
- Addition of parameters to create dead plants or to have missing plants (holes) in grapevine canopies
- Addition of parameters to set the cordon length independently from the plant spacing for grapevine canopies. Until now, the plant spacing was used so that there was no discontinuity between neighbor vine stocks. These new parameters allow to potentially have gaps between vine stocks, or even have them overlap with each other (if the cordon length is greater than the plant spacing).
- Addition of a sample project to demonstrate how one could build realistic vineyards based on CanopyGenerator XML configuration.

Note: Adding Tong Lei <luyaz999> as co-author retroactively based on contributions to previous versions that were not listed.

Co-authored-by: leroycorentin
Co-authored-by: smbanx
Co-authored-by: luyaz999

CONTRIBUTING.md

@@ -0,0 +1,43 @@
+# Contributing to Helios
+
+Thanks for contributing to [Helios](https://github.com/PlantSimulationLab/Helios)!
+
+The following set of guidelines should be taken as suggestion, rather than rules.  These are currently a work-in-progress, and will evolve along with the project.
+
+If you have comments or suggestions, please feel free to [open an issue](https://github.com/PlantSimulationLab/Helios/issues/new) or [submit a pull-request](https://github.com/PlantSimulationLab/Helios/compare) to this file.
+
+## Editing Documentation
+
+Documentation source files for the Helios core can be found in `doc/UserGuide.dox`, and for each plugin in the corresponding plug-in directory sub-folder `doc/*.dox`. These files are written in [Doxygen](https://www.doxygen.nl/index.html) format. Additionally, documentation for data structures, functions, methods, etc. is written directly in the corresponding header file, and also uses Doxygen syntax.
+
+If you edit the documentation and want to view the changes, you can build the documentation HTML files. To do this, you need to have Doxygen installed on your system. Then, navigate to the Helios root directory and run:
+
+```bash
+doxygen doc/Doxyfile
+```
+
+To view the built documentation, open the file `doc/html/index.html` in a web browser.
+
+## Submitting Changes
+
+To submit a change, please submit a pull request. There are two methods for doing this if you do not have a 'contributor' role in the Helios repo:
+
+1. Fork the Helios repo, push changes to a branch, and [create a pull-request on github](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork).  
+2. You can use the GitHub web interface to [submit a pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request).
+
+Please make edits to the latest version of the master to the extent possible in order to allow for straight-forward merging of the changes into the master. Pull requests should include a clear list of changes summarizing the overall contents of the change.
+
+Each individual commits should be prefaced with a one-line summary of the intended change.  Large and complex commits may also include a longer description, separated by at least one line:
+
+```
+$ git commit -m "A brief summary of the commit.
+> 
+> A paragraph describing the change in greater detail."
+```
+
+## Style Guide
+
+Below are a few general guidelines to follow when contributing to Helios:
+1. **Case**: Helios generally uses UpperCamelCase for class names, lowerCamelCase for method names, and snake_case for variable names.
+2. **Const Ref**: Use const references (const &) for function/method arguments when passing non-scalar values.
+

core/include/Context.h

@@ -4347,6 +4347,12 @@ class Context{
      * \return Size/length of global data array
      */
     size_t getGlobalDataSize( const char* label ) const;
+
+    //! List the labels for all global data in the Context
+    /**
+     * \return Vector of labels for all global data
+     */
+    std::vector<std::string> listGlobalData() const;
 
     //! Check if global data 'label' exists
     /**

core/include/helios_vector_types.h

@@ -352,10 +352,11 @@ struct vec2{
   float y;
 
   //! Normalize vector components such that the magnitude is unity.
-  void normalize(){
+  vec2 normalize(){
     float mag = sqrt( x*x + y*y );
     x/=mag;
     y/=mag;
+    return {x,y};
   }
 
   //! Compute the vector magnitude 
@@ -510,11 +511,12 @@ struct vec3{
   float z;
 
   //! Normalize vector components such that the magnitude is unity.
-  void normalize(){
+  vec3 normalize(){
     float mag = sqrt( x*x + y*y + z*z );
     x/=mag;
     y/=mag;
     z/=mag;
+    return {x,y,z};
   }
 
   //! Compute the vector magnitude 
@@ -681,12 +683,13 @@ struct vec4{
   float w;
 
   //! Normalize vector components such that the magnitude is unity.
-  void normalize(){
+  vec4 normalize(){
     float mag = sqrt( x*x + y*y + z*z + w*w );
     x/=mag;
     y/=mag;
     z/=mag;
     w/=mag;
+    return {x,y,z,w};
   }
 
   //! Compute the vector magnitude