Documentation source update detected and pushed compilation build dir…

…ectory for Github Pages

docs/compilation/main/.buildinfo

@@ -1,4 +1,4 @@
 # Sphinx build info version 1
 # This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
-config: 61fa2a6f0f119d56d0e43458418bd984
+config: b37f97fa7080ff5c795c444e621cd363
 tags: 645f666f9bcd5a90fca523b33c5a78b7

docs/compilation/main/.doctrees/nbsphinx/pages/notebooks/basic_example.ipynb

@@ -20,9 +20,9 @@
     }
    },
    "source": [
-    "Sinergym uses the standard [Farama Gymnasium API](https://gymnasium.farama.org/index.html). Lets see how to create a basic loop.\n",
+    "Sinergym utilizes the standard [Farama Gymnasium API](https://gymnasium.farama.org/index.html). Let's explore how to create a basic loop.\n",
     "\n",
-    "First, we need to include Sinergym and to create an environment, in our case using `Eplus-demo-v1`"
+    "To begin, we need to import Sinergym and create an environment. In this example, we will use the `Eplus-demo-v1` environment.\n"
    ]
   },
   {
@@ -72,10 +72,9 @@
     }
    },
    "source": [
-    "At first glance, it may appear that Sinergym is only imported, but never used. Importing Sinergym, all its [Environments](https://ugr-sail.github.io/sinergym/compilation/html/pages/environments.html)\n",
-    "are defined to be used. In this case, `Eplus-demo-v1` is available with all the features contained.\n",
+    "At first glance, Sinergym might seem to be only imported and not used. However, importing Sinergym inherently defines all its [Environments](https://ugr-sail.github.io/sinergym/compilation/html/pages/environments.html) for use. In this instance, `Eplus-demo-v1` is readily available with all its features.\n",
     "\n",
-    "After this simple definition, we are ready to loop the episodes. For this simple example, we are going to consider only 1 episode. In summary, the code which we need is something like this:"
+    "With this straightforward setup, we're prepared to iterate over the episodes. For this basic example, we'll consider just one episode. Essentially, the required code would look something like this:"
    ]
   },
   {
@@ -157,7 +156,7 @@
     }
    },
    "source": [
-    "And, as always, don't forget to close the environment when the interaction finishes:"
+    "As always, remember to close the environment once the interaction is complete:"
    ]
   },
   {
@@ -192,7 +191,7 @@
     }
    },
    "source": [
-    "Now, we can see the final rewards:"
+    "Now, let's examine the final rewards:"
    ]
   },
   {
@@ -226,7 +225,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "The [list of environments](https://github.com/ugr-sail/sinergym/blob/main/sinergym/__init__.py) that we have registered in Sinergym is extensive and we use buildings files changing particularities. For example, continuous or discrete action spaces, different types of weathers, noise over weather, runperiod, timesteps, reward functions, etc. We will see it in the following notebooks."
+    "Sinergym has an extensive [list of registered environments](https://github.com/ugr-sail/sinergym/blob/main/sinergym/__init__.py). We utilize building files with varying characteristics, such as continuous or discrete action spaces, different weather types, weather noise, run periods, timesteps, reward functions, and more. We'll explore these in the upcoming notebooks."
    ]
   }
  ],

docs/compilation/main/.doctrees/nbsphinx/pages/notebooks/change_environment.ipynb

@@ -20,7 +20,7 @@
     }
    },
    "source": [
-    "As discussed above, Sinergym has a list of available environments which we can call with `gym.make(<environment_id>)` as long as the Sinergym package is imported into the python script."
+    "To use the available environments in Sinergym, simply import the Sinergym package and call `gym.make(<environment_id>)` in your Python script. The list of available environments can be found in the Sinergym documentation.\n"
    ]
   },
   {
@@ -65,17 +65,17 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "These environment ID's have a number of components defined, not only the building design (*epJSON*), but also the reward function, the action and observation spaces, the definition of variables, meters and actuators, etc.\n",
+    "Environment IDs in Sinergym encompass various components, including the building design (*epJSON*), reward function, action and observation spaces, variable definitions, meters, actuators, and more.\n",
     "\n",
-    "If you want a new environment, you can define it from scratch in our [environment list](https://github.com/ugr-sail/sinergym/blob/main/sinergym/__init__.py) (take the env demo as example) and run it locally.\n",
+    "If you wish to create a new environment, you can define it from scratch in our [environment list](https://github.com/ugr-sail/sinergym/blob/main/sinergym/__init__.py) (use the env demo as an example) and run it locally.\n",
     "\n",
-    "Another option (recommended) is starting from one of our environments ID and changing the components you want. You can combine different components obviously.\n",
+    "Alternatively (and recommended), you can start with one of our environment IDs and modify the components as needed. You can mix and match different components.\n",
     "\n",
-    "The way to do that is to add in the `gym.make(<environment_id>)` those parameters of the constructor of the *Sinergym* environment we want to overwrite. \n",
+    "To do this, add the parameters you want to overwrite in the `gym.make(<environment_id>)` constructor of the *Sinergym* environment.\n",
     "\n",
-    "Many of this updates require the building model changes in order to adapt it to this new features, this will be made by Sinergym automatically. For example, using another weather file requires building location and design days update, using new observation variables requires to update the `Output:Variable` fields, the same occurs with extra configuration context concerned with simulation directly. This new building file version, is saved in the Sinergym output folder, leaving the original intact.\n",
+    "Many of these updates necessitate changes to the building model to accommodate new features. Sinergym will automatically handle these changes. For instance, using a different weather file requires updating the building location and design days. Similarly, using new observation variables requires updating the `Output:Variable` fields. The same applies to any additional configuration context directly related to the simulation. Sinergym saves this new building file version in its output folder, leaving the original untouched.\n",
     "\n",
-    "Let's see some things we can update starting from any environment:"
+    "Let's explore some of the elements we can update from any environment:"
    ]
   },
   {
@@ -139,7 +139,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "You have to specify the **reward** class you are going to use in the environment. A reward function class has several parameters that can be specified by user like temperature variables, weights, etc. Depending on the reward function you are using. In order to be able to define it, we have **reward_kwargs** parameter. See [reward documentation](https://ugr-sail.github.io/sinergym/compilation/html/pages/rewards.html) for more information about reward classes and how to create a new one. "
+    "You need to define the **reward** class for the environment. A reward function class has various user-specifiable parameters, such as temperature variables, weights, etc., depending on the chosen reward function. To define it, we use the **reward_kwargs** parameter. Refer to the [reward documentation](https://ugr-sail.github.io/sinergym/compilation/html/pages/rewards.html) for more details on reward classes and how to create a new one."
    ]
   },
   {
@@ -155,7 +155,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "It is possible to substitute the weather file (and the weather variability if you want a stochastic environment) used in the environment by a new one. The methodology is the same than the reward example:"
+    "You can replace the weather file (and weather variability for a stochastic environment) used in the environment with a new one. The approach is the same as the reward example:"
    ]
   },
   {
@@ -191,7 +191,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "It is possible to **add more than one weather** file too. In that case, Sinergym will select one of the available weathers randomly and will adapt the building model to that location in each episode:"
+    "You can also **add multiple weather** files. In this scenario, Sinergym will randomly select one of the available weather files and adjust the building model to that location for each episode:"
    ]
   },
   {
@@ -235,10 +235,9 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "By default, the IDs of the predefined environments in *Sinergym* already have the **time variables**, **variables**, **meters** and **actuators** set up, together observation (time variables, variables and meters) and action (actuators) spaces for those components.\n",
+    "By default, the IDs of the predefined environments in *Sinergym* come with **time variables**, **variables**, **meters**, and **actuators** preconfigured, along with observation (time variables, variables, and meters) and action (actuators) spaces for these components.\n",
     "\n",
-    "However, it can be overwritten by a new definition of them. On the one hand, we will have to define the name of the \n",
-    "**time variables**, **variables**, **meters** or **actuators**, and on the other hand, the definition of the **action space** (and an **action mapping** if it is a discrete environment). Observation space is calculated automatically by Sinergym. It is possible to change a subset of these components too. For more information about the structure definitions shown bellow, visit the documentation."
+    "However, these can be overwritten with new definitions. We'll need to define the names of the **time variables**, **variables**, **meters**, or **actuators**, as well as the **action space** definition (and an **action mapping** for discrete environments). Sinergym automatically calculates the observation space. It's also possible to modify a subset of these components. For more details on the structure definitions shown below, refer to the documentation."
    ]
   },
   {
@@ -379,11 +378,9 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "In case the definition has some inconsistency, such as the spaces do not fit with the variables, the \n",
-    "observation variables do not exist, etc. *Sinergym* will display an error.\n",
+    "If the definition contains inconsistencies, such as mismatched spaces and variables, or non-existent observation variables, *Sinergym* will throw an error.\n",
     "\n",
-    "The time variables, variables, meters or actuators definition must be correct for Energyplus Engine.\n",
-    "Otherwise, an error message will be shown by Sinergym. See documentation for more information.\n"
+    "The definitions for time variables, variables, meters, or actuators must be compatible with the EnergyPlus Engine. If not, Sinergym will display an error message. Refer to the documentation for more details.\n"
    ]
   },
   {
@@ -398,7 +395,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "It is possible to update any argument of the environment constructor in Sinergym. Consequently, we can make other changes such as the name of the environment or the maximum number of episodes it will store in its output or the normalization in the gym actions interface."
+    "In Sinergym, any argument of the environment constructor can be updated. This allows for modifications such as changing the environment name, adjusting the maximum number of episodes stored in its output, or altering the normalization in the gym actions interface."
    ]
   },
   {
@@ -436,7 +433,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "You can even add a dictionary with extra parameters that update building model with some new context concerned with simulation directly:"
+    "You can also include a dictionary with additional parameters to update the building model directly with new simulation-related context:"
    ]
   },
   {

docs/compilation/main/.doctrees/nbsphinx/pages/notebooks/default_building_control.ipynb

@@ -20,21 +20,21 @@
     }
    },
    "source": [
-    "When you want to run a simulation with all the default building control (specified in the building file). You can directly use the **EnergyPlus simulation engine**. For example, placing us in the workspace of the container, it would be to run the following:\n",
+    "If you wish to run a simulation with all the default building controls (as specified in the building file), you can directly use the **EnergyPlus simulation engine**. For instance, from the container's workspace, you could run the following command:\n",
     "\n",
     "```bash\n",
     "$ energyplus -w sinergym/data/weather/USA_PA_Pittsburgh-Allegheny.County.AP.725205_TMY3.epw sinergym/data/buildings/5ZoneAutoDXVAV.epJSON\n",
     "```\n",
     "\n",
-    "However, doing so without our framework has some **disadvantages**. You will have EnergyPlus default output and will not have some **added outputs** such as our wrapper logger that monitors all interactions with the environment. The buildings have a default *Site:Location* and *SizingPeriod:DesignDay*, which Sinergym changes automatically depending on the specified weather, so you would have to **adjust it** before using the simulator manually. Finally, the *RunPeriod* of the buildings are set to one episode for DRL, which means that as the buildings stand you can only simulate one year. So, you would also have to modify the *RunPeriod* **manually** in the building file before starting the simulation."
+    "However, doing this without our framework has some **drawbacks**. You'll only have the default EnergyPlus output and won't have access to some **additional outputs**, such as our wrapper logger that tracks all environment interactions. The buildings have a default *Site:Location* and *SizingPeriod:DesignDay*, which Sinergym automatically adjusts based on the specified weather, so you'd need to **modify** these before manually using the simulator. Lastly, the buildings' *RunPeriod* is set to one episode for DRL, meaning you can only simulate one year as it currently stands. Therefore, you'd also need to **manually** adjust the *RunPeriod* in the building file before starting the simulation."
    ]
   },
   {
    "attachments": {},
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Therefore, our recommended proposal is setting up an **empty action interface** in an environment with Sinergym. For example:"
+    "Hence, we recommend setting up an **empty action interface** in a Sinergym environment. For instance:"
    ]
   },
   {
@@ -157,9 +157,9 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "In this example, a default environment is loaded, but the space and definition of the default action **is replaced with an empty one**, Sinergym takes care of making the necessary changes in the background. Then, the random agent implemented send **empty actions ([])**.\n",
+    "In this example, a default environment is loaded, but the space and definition of the default action **are replaced with an empty one**. Sinergym handles the necessary background changes. The implemented random agent then sends **empty actions ([])**.\n",
     "\n",
-    "The advantages are that you can **combine the weathers with the buildings** as you want, Sinergym will take care of adapting everything automatically (you don't have the disadvantages of before), you can run in a single experiment as many years as you want, with our loggers. You can decide which observation variables you want in a more comfortable way too. When you set an empty action interface, Sinergym preserves the default actuators that the building definition comes with (these can be more or less sophisticated depending on the definition of the building in the *epJSON* file)."
+    "The benefits of this approach include the ability to **mix and match weathers and buildings** as desired, with Sinergym automatically making all necessary adjustments (avoiding the previously mentioned disadvantages). You can run as many years as you want in a single experiment, using our loggers. You also have more flexibility in choosing which observation variables you want. When you set an empty action interface, Sinergym retains the default actuators that come with the building definition (these can vary in sophistication depending on the building definition in the *epJSON* file)."
    ]
   }
  ],