Jupyter fixes IMAGES calls

Some of the images are not showing because they are labeled '.png' instead of 'PNG'. Modified
NREL · May 21, 2020 · 9705acd · 9705acd
1 parent 011865d
commit 9705acd
Show file tree

Hide file tree

Showing 6 changed files with 22 additions and 22 deletions.
diff --git a/docs/tutorials/1 - Introductory Example - Fixed Tilt simple setup.ipynb b/docs/tutorials/1 - Introductory Example - Fixed Tilt simple setup.ipynb
@@ -132,7 +132,7 @@
     "This will create all the folder structure of the bifacial_radiance Scene in the designated testfolder in your computer, and it should look like this:\n",
     "\n",
     "\n",
-    "![Folder Structure](../images_wiki/Journal1Pics/folderStructure.png)"
+    "![Folder Structure](../images_wiki/Journal1Pics/folderStructure.PNG)"
    ]
   },
   {
@@ -799,7 +799,7 @@
    "source": [
     "As can be seen in the results for the *Wm2Front* and *WM2Back*, the irradiance values are quite high. This is because a cumulative sky simulation was performed on <b> step 5 </b>, so this is the total irradiance over all the hours of the year that the module at each sampling point will receive. Dividing the back irradiance average by the front irradiance average will give us the bifacial gain for the year:\n",
     "\n",
-    "![Bifacial Gain in Irradiance Formula](../images_wiki/Journal1Pics/BGG_Formula.png)\n",
+    "![Bifacial Gain in Irradiance Formula](../images_wiki/Journal1Pics/BGG_Formula.PNG)\n",
     "\n",
     "Assuming that our module from Prism Solar has a bifaciality factor (rear to front performance) of 90%, our <u> bifacial gain </u> is of:"
    ]
@@ -877,7 +877,7 @@
    "source": [
     "This is how the False Color image stored in images folder should look like:\n",
     "\n",
-    "![OpenHDR image example of False color](../images_wiki/Journal1Pics/openhdr_FalseColorExample.png)"
+    "![OpenHDR image example of False color](../images_wiki/Journal1Pics/openhdr_FalseColorExample.PNG)"
    ]
   },
   {
@@ -906,7 +906,7 @@
    "name": "python",
    "nbconvert_exporter": "python",
    "pygments_lexer": "ipython3",
-   "version": "3.7.4"
+   "version": "3.7.3"
   }
  },
  "nbformat": 4,

diff --git a/docs/tutorials/1 - Introductory Example - Fixed Tilt simple setup.py b/docs/tutorials/1 - Introductory Example - Fixed Tilt simple setup.py
@@ -76,7 +76,7 @@
 # This will create all the folder structure of the bifacial_radiance Scene in the designated testfolder in your computer, and it should look like this:
 # 
 # 
-# ![Folder Structure](../images_wiki/Journal1Pics/folderStructure.png)
+# ![Folder Structure](../images_wiki/Journal1Pics/folderStructure.PNG)
 
 # <a id='step3'></a>
 
@@ -264,7 +264,7 @@
 
 # As can be seen in the results for the *Wm2Front* and *WM2Back*, the irradiance values are quite high. This is because a cumulative sky simulation was performed on <b> step 5 </b>, so this is the total irradiance over all the hours of the year that the module at each sampling point will receive. Dividing the back irradiance average by the front irradiance average will give us the bifacial gain for the year:
 # 
-# ![Bifacial Gain in Irradiance Formula](../images_wiki/Journal1Pics/BGG_Formula.png)
+# ![Bifacial Gain in Irradiance Formula](../images_wiki/Journal1Pics/BGG_Formula.PNG)
 # 
 # Assuming that our module from Prism Solar has a bifaciality factor (rear to front performance) of 90%, our <u> bifacial gain </u> is of:
 
@@ -303,7 +303,7 @@
 
 # This is how the False Color image stored in images folder should look like:
 # 
-# ![OpenHDR image example of False color](../images_wiki/Journal1Pics/openhdr_FalseColorExample.png)
+# ![OpenHDR image example of False color](../images_wiki/Journal1Pics/openhdr_FalseColorExample.PNG)
 
 # Files are saved as .hdr (high definition render) files.  Try LuminanceHDR viewer (free) to view them, or https://viewer.openhdr.org/ 
 # 

diff --git a/docs/tutorials/2 - Introductory Example - Single Axis Tracking with cumulative Sky.ipynb b/docs/tutorials/2 - Introductory Example - Single Axis Tracking with cumulative Sky.ipynb
@@ -8,7 +8,7 @@
     "\n",
     "Method <b> Gencumsky </b> has been modified to divide the yearly-cumulative sky into various skies, each one representing the cumulative irradiance for the hours at which the tracker is at a certain angle. For faster running, for a tracker that moves between 45 and -45 degrees limit angle, if only positions every 5 degrees are considered (45, 40, 35 .... -4-, -45), then only 18 skies (and 18 simulations) will be run for the whole year.\n",
     "\n",
-    "![Example of the hemisphere cumulative sky](../images_wiki/Journal2Pics/tracking_cumulativesky.png)\n",
+    "![Example of the hemisphere cumulative sky](../images_wiki/Journal2Pics/tracking_cumulativesky.PNG)\n",
     "\n",
     "\n",
     "This procedure was presented in:\n",
@@ -139,7 +139,7 @@
     "This will create all the folder structure of the bifacial_radiance Scene in the designated testfolder in your computer, and it should look like this:\n",
     "\n",
     "\n",
-    "![Folder Structure](../images_wiki/Journal1Pics/folderStructure.png)"
+    "![Folder Structure](../images_wiki/Journal1Pics/folderStructure.PNG)"
    ]
   },
   {
@@ -372,7 +372,7 @@
    "source": [
     "This is how one of the cumulative sky .cal files associated with each .rad file generated look like: \n",
     "\n",
-    "![Example of the gencumsky1axis](../images_wiki/Journal2Pics/gencumsky1axis_example_file_structure_and_contents.png)\n",
+    "![Example of the gencumsky1axis](../images_wiki/Journal2Pics/gencumsky1axis_example_file_structure_and_contents.PNG)\n",
     "\n",
     "\n",
     "Each of the values corresponds to the cumulative rradiance of one of those patches, for when the tracker is at that specific angle through the year."
@@ -819,7 +819,7 @@
     "II. Sensors sample always in the same direction. For this N-S aligned tracker, that is East-most to West. For this 2-up portrait tracker which is 3.5 meters, 20x7 rows and we are sampling module 9 on row 2, the East to West sampling goes from 22.6 m to 19.81 m = 2.79m. It is not exatly 3.5 because the sensors are spaced evenly through the collector width (CW): \n",
     "\n",
     "\n",
-    "![Sensors spaced along collector width](../images_wiki/Journal2Pics/spaced_sensors.png)\n",
+    "![Sensors spaced along collector width](../images_wiki/Journal2Pics/spaced_sensors.PNG)\n",
     "\n",
     "III. When there is a ygap in the collector width (2-UP or more configuration), some of the sensors might end up sampling the torque tube, or the sky. You can ses that in the materials columns. This also happens if the number of sensors is quite high, the edges of the module might be sampled instead of the sensors. For this reason, before calculating bifacial gain these results must be cleaned. For more advanced simulations, make sure you clean each result csv file individually.  We provide some options on load.py but some are very use-specific, so you might have to develop your own cleaning tool (or let us know on issues!)\n",
     "\n",
@@ -1058,7 +1058,7 @@
    "source": [
     "These are the total irradiance values over all the hours of the year that the module at each sampling point will receive. Dividing the back irradiance average by the front irradiance average will give us the bifacial gain for the year:\n",
     "\n",
-    "![Bifacial Gain in Irradiance Formula](../images_wiki/Journal1Pics/BGG_Formula.png)\n",
+    "![Bifacial Gain in Irradiance Formula](../images_wiki/Journal1Pics/BGG_Formula.PNG)\n",
     "\n",
     "Assuming that our module from Prism Solar has a bifaciality factor (rear to front performance) of 90%, our <u> bifacial gain </u> is of:"
    ]

diff --git a/docs/tutorials/2 - Introductory Example - Single Axis Tracking with cumulative Sky.py b/docs/tutorials/2 - Introductory Example - Single Axis Tracking with cumulative Sky.py
@@ -5,7 +5,7 @@
 # 
 # Method <b> Gencumsky </b> has been modified to divide the yearly-cumulative sky into various skies, each one representing the cumulative irradiance for the hours at which the tracker is at a certain angle. For faster running, for a tracker that moves between 45 and -45 degrees limit angle, if only positions every 5 degrees are considered (45, 40, 35 .... -4-, -45), then only 18 skies (and 18 simulations) will be run for the whole year.
 # 
-# ![Example of the hemisphere cumulative sky](../images_wiki/Journal2Pics/tracking_cumulativesky.png)
+# ![Example of the hemisphere cumulative sky](../images_wiki/Journal2Pics/tracking_cumulativesky.PNG)
 # 
 # 
 # This procedure was presented in:
@@ -82,7 +82,7 @@
 # This will create all the folder structure of the bifacial_radiance Scene in the designated testfolder in your computer, and it should look like this:
 # 
 # 
-# ![Folder Structure](../images_wiki/Journal1Pics/folderStructure.png)
+# ![Folder Structure](../images_wiki/Journal1Pics/folderStructure.PNG)
 
 # <a id='step3'></a>
 
@@ -169,7 +169,7 @@
 
 # This is how one of the cumulative sky .cal files associated with each .rad file generated look like: 
 # 
-# ![Example of the gencumsky1axis](../images_wiki/Journal2Pics/gencumsky1axis_example_file_structure_and_contents.png)
+# ![Example of the gencumsky1axis](../images_wiki/Journal2Pics/gencumsky1axis_example_file_structure_and_contents.PNG)
 # 
 # 
 # Each of the values corresponds to the cumulative rradiance of one of those patches, for when the tracker is at that specific angle through the year.
@@ -276,7 +276,7 @@
 # II. Sensors sample always in the same direction. For this N-S aligned tracker, that is East-most to West. For this 2-up portrait tracker which is 3.5 meters, 20x7 rows and we are sampling module 9 on row 2, the East to West sampling goes from 22.6 m to 19.81 m = 2.79m. It is not exatly 3.5 because the sensors are spaced evenly through the collector width (CW): 
 # 
 # 
-# ![Sensors spaced along collector width](../images_wiki/Journal2Pics/spaced_sensors.png)
+# ![Sensors spaced along collector width](../images_wiki/Journal2Pics/spaced_sensors.PNG)
 # 
 # III. When there is a ygap in the collector width (2-UP or more configuration), some of the sensors might end up sampling the torque tube, or the sky. You can ses that in the materials columns. This also happens if the number of sensors is quite high, the edges of the module might be sampled instead of the sensors. For this reason, before calculating bifacial gain these results must be cleaned. For more advanced simulations, make sure you clean each result csv file individually.  We provide some options on load.py but some are very use-specific, so you might have to develop your own cleaning tool (or let us know on issues!)
 # 
@@ -302,7 +302,7 @@
 
 # These are the total irradiance values over all the hours of the year that the module at each sampling point will receive. Dividing the back irradiance average by the front irradiance average will give us the bifacial gain for the year:
 # 
-# ![Bifacial Gain in Irradiance Formula](../images_wiki/Journal1Pics/BGG_Formula.png)
+# ![Bifacial Gain in Irradiance Formula](../images_wiki/Journal1Pics/BGG_Formula.PNG)
 # 
 # Assuming that our module from Prism Solar has a bifaciality factor (rear to front performance) of 90%, our <u> bifacial gain </u> is of:
 

diff --git a/docs/tutorials/3 - Medium Level Example - Single Axis Tracking - hourly.ipynb b/docs/tutorials/3 - Medium Level Example - Single Axis Tracking - hourly.ipynb
@@ -237,11 +237,11 @@
     "In this example we passed the parameter \"pitch\". Pitch is the spacing between rows (for example, between hub-posts) in a field.\n",
     "To calculate Ground Coverage Ratio (GCR), we must relate the pitch to the collector-width by:\n",
     "    \n",
-    "![GCR = CW / pitch](../images_wiki/Journal3Pics/Equation_GCR.png)\n",
+    "![GCR = CW / pitch](../images_wiki/Journal3Pics/Equation_GCR.PNG)\n",
     "\n",
     "The collector width for our system must consider the number of panels and the y-gap:\n",
     "    \n",
-    "![CW](../images_wiki/Journal3Pics/Equation_CW.png)\n",
+    "![CW](../images_wiki/Journal3Pics/Equation_CW.PNG)\n",
     "    \n",
     "Collector Width gets saved in your module parameters (and later on your scene and trackerdict) as \"sceney\". You can calculate your collector width with the equation, or you can use this method to know your GCR:"
    ]
@@ -1164,7 +1164,7 @@
    "name": "python",
    "nbconvert_exporter": "python",
    "pygments_lexer": "ipython3",
-   "version": "3.7.4"
+   "version": "3.7.3"
   }
  },
  "nbformat": 4,

diff --git a/docs/tutorials/3 - Medium Level Example - Single Axis Tracking - hourly.py b/docs/tutorials/3 - Medium Level Example - Single Axis Tracking - hourly.py
@@ -149,11 +149,11 @@
 # In this example we passed the parameter "pitch". Pitch is the spacing between rows (for example, between hub-posts) in a field.
 # To calculate Ground Coverage Ratio (GCR), we must relate the pitch to the collector-width by:
 #     
-# ![GCR = CW / pitch](../images_wiki/Journal3Pics/Equation_GCR.png)
+# ![GCR = CW / pitch](../images_wiki/Journal3Pics/Equation_GCR.PNG)
 # 
 # The collector width for our system must consider the number of panels and the y-gap:
 #     
-# ![CW](../images_wiki/Journal3Pics/Equation_CW.png)
+# ![CW](../images_wiki/Journal3Pics/Equation_CW.PNG)
 #     
 # Collector Width gets saved in your module parameters (and later on your scene and trackerdict) as "sceney". You can calculate your collector width with the equation, or you can use this method to know your GCR: