docs: Update Documentation

.gitignore

@@ -32,6 +32,7 @@ results
 neps_examples/results
 tests_tmpdir
 usage_example
+lightning_logs
 
 # Regression tests
 !losses.json

docs/getting_started.md

@@ -51,23 +51,22 @@ neps.run(evaluate_pipeline, pipeline_space)
 
 The [reference](reference/neps_run.md) section provides detailed information on the individual components of NePS.
 
-1. How to use the **[`neps.run()` function](reference/neps_run.md)** to start the optimization process.
+1. How to use the [**`neps.run()`** function](reference/neps_run.md) to start the optimization process.
 2. The different [search space](reference/pipeline_space.md) options available.
 3. How to choose and configure the [optimizer](reference/optimizers.md) used.
-4. [Declarative usage](reference/declarative_usage.md) of NePS via YAML configuration files.
-5. How to define the [`evaluate_pipeline()` function](reference/evaluate_pipeline.md).
-6. How to use the [CLI](reference/cli.md) to run NePS from the command line.
-7. How to [analyze](reference/analyse.md) the optimization runs.
+4. How to define the [`evaluate_pipeline()` function](reference/evaluate_pipeline.md).
+5. How to use the [CLI](reference/cli.md) to run NePS from the command line.
+6. How to [analyze](reference/analyse.md) the optimization runs.
 
 Or discover the features of NePS through these practical examples:
 
-* **[Hyperparameter Optimization (HPO)](examples/template/basic.md)**:
+* **[Hyperparameter Optimization (HPO)](examples/basic_usage/hyperparameters.md)**:
 Learn the essentials of hyperparameter optimization with NePS.
 
 * **[Multi-Fidelity Optimization](examples/efficiency/multi_fidelity.md)**:
 Understand how to leverage multi-fidelity optimization for efficient model tuning.
 
-* **[Utilizing Expert Priors for Hyperparameters](examples/template/priorband.md)**:
+* **[Utilizing Expert Priors for Hyperparameters](examples/efficiency/expert_priors_for_hyperparameters.md)**:
 Learn how to incorporate expert priors for more efficient hyperparameter selection.
 
 * **[Additional NePS Examples](examples/index.md)**:

docs/index.md

@@ -46,10 +46,10 @@ pip install neural-pipeline-search
 
 Using `neps` always follows the same pattern:
 
-1. Define a `evalute_pipeline` function capable of evaluating different architectural and/or hyperparameter configurations
+1. Define a `evaluate_pipeline` function capable of evaluating different architectural and/or hyperparameter configurations
    for your problem.
 1. Define a search space named `pipeline_space` of those Parameters e.g. via a dictionary
-1. Call `neps.run` to optimize `evalute_pipeline` over `pipeline_space`
+1. Call `neps.run` to optimize `evaluate_pipeline` over `pipeline_space`
 
 In code, the usage pattern can look like this:
 
@@ -59,7 +59,7 @@ import logging
 
 
 # 1. Define a function that accepts hyperparameters and computes the validation error
-def evalute_pipeline(
+def evaluate_pipeline(
         hyperparameter_a: float, hyperparameter_b: int, architecture_parameter: str
 ) -> dict:
     # Create your model
@@ -72,7 +72,7 @@ def evalute_pipeline(
     return validation_error
 
 
-# 2. Define a search space of parameters; use the same parameter names as in evalute_pipeline
+# 2. Define a search space of parameters; use the same parameter names as in evaluate_pipeline
 pipeline_space = dict(
     hyperparameter_a=neps.Float(
         lower=0.001, upper=0.1, log=True  # The search space is sampled in log space
@@ -84,7 +84,7 @@ pipeline_space = dict(
 # 3. Run the NePS optimization
 logging.basicConfig(level=logging.INFO)
 neps.run(
-    evalute_pipeline=evalute_pipeline,
+    evaluate_pipeline=evaluate_pipeline,
     pipeline_space=pipeline_space,
     root_directory="path/to/save/results",  # Replace with the actual path.
     max_evaluations_total=100,

docs/reference/analyse.md

@@ -51,13 +51,12 @@ NePS will also generate a summary CSV file for you.
     │  └── config_1
     │      ├── config.yaml
     │      ├── metadata.yaml
-    │      └── result.yaml
-    ├── summary_csv
-    │  ├── config_data.csv
-    │  └── run_status.csv
-    ├── all_losses_and_configs.txt
-    ├── best_loss_trajectory.txt
-    └── best_loss_with_config_trajectory.txt
+    │      └── report.yaml
+    ├── summary
+    │  ├── full.csv
+    │  └── short.csv
+    ├── optimizer_info.yaml
+    └── optimizer_state.pkl
     ```
 
 
@@ -69,17 +68,17 @@ NePS will also generate a summary CSV file for you.
     │  └── config_1
     │      ├── config.yaml
     │      ├── metadata.yaml
-    │      └── result.yaml
-    ├── all_losses_and_configs.txt
-    ├── best_loss_trajectory.txt
-    └── best_loss_with_config_trajectory.txt
+    │      └── report.yaml
+    ├── optimizer_info.yaml
+    └── optimizer_state.pkl
     ```
 
 
-The `config_data.csv` contains all configuration details in CSV format, ordered by ascending `loss`.
-Details include configuration hyperparameters, any returned result from the `evalute_pipeline` function, and metadata information.
+The `full.csv` contains all configuration details in CSV format.
+Details include configuration hyperparameters and any returned result and cost from the `evaluate_pipeline` function.
 
-The `run_status.csv` provides general run details, such as the number of sampled configs, best configs, number of failed configs, best loss, etc.
+The `run_status.csv` provides general run details, such as the number of failed and successful configurations,
+and the best configuration with its corresponding objective value.
 
 # TensorBoard Integration
 

docs/reference/cli.md

@@ -35,14 +35,14 @@ Executes the optimization based on the provided configuration. This command serv
 - `--evaluate-pipeline` (Optional): Optional: Provide the path to a Python file and a function name separated by a colon, e.g., 'path/to/module.py:function_name'. If provided, it overrides the evaluate_pipeline setting from the YAML configuration.
 - `--pipeline-space` (Optional): Path to the YAML file defining the search space for the optimization. This can be provided here or defined within the 'run_args' YAML file.
 - `--root-directory` (Optional): The directory to save progress to. This is also used to synchronize multiple calls for parallelization.
-- `--overwrite-working-directory` (Optional): If set, deletes the working directory at the start of the run. This is useful, for example, when debugging a evalute_pipeline function.
+- `--overwrite-working-directory` (Optional): If set, deletes the working directory at the start of the run. This is useful, for example, when debugging a evaluate_pipeline function.
 - `--post-run-summary` (Optional): Provide a summary of the results after running.
 - `--no-post-run-summary` (Optional): Do not provide a summary of the results after running.
 - `--max-evaluations-total` (Optional): Total number of evaluations to run.
 - `--max-evaluations-per-run` (Optional): Number of evaluations a specific call should maximally do.
 - `--continue-until-max-evaluation-completed` (Optional): If set, only stop after max-evaluations-total have been completed. This is only relevant in the parallel setting.
 - `--max-cost-total` (Optional): No new evaluations will start when this cost is exceeded. Requires returning a cost
-  in the evalute_pipeline function.
+  in the evaluate_pipeline function.
 - `--ignore-errors` (Optional): If set, ignore errors during the optimization process.
 - `--loss-value-on-error` (Optional): Loss value to assume on error.
 - `--cost-value-on-error` (Optional): Cost value to assume on error.

docs/reference/evaluate_pipeline.md

@@ -1,4 +1,4 @@
-# The run function
+# The evaluate function
 
 ## Introduction
 
@@ -108,39 +108,39 @@ Each evaluation carries a cost of 2. Hence in this example, the Bayesian optimiz
 
 NePS also provides the `pipeline_directory` and the `previous_pipeline_directory` as arguments in the `evaluate_pipeline=` function for user convenience.
 
-Regard an example to be run with a multi-fidelity optimizer, some checkpointing would be advantageos such that one does not have to train the configuration from scratch when the configuration qualifies to higher fidelity brackets.
+Regard an example to be run with a multi-fidelity optimizer, some checkpointing would be advantageous such that one does not have to train the configuration from scratch when the configuration qualifies to higher fidelity brackets.
 
 ```python
 def evaluate_pipeline(
     pipeline_directory,           # The directory where the config is saved
     previous_pipeline_directory,  # The directory of the immediate lower fidelity config
     **config,                     # The hyperparameters to be used in the pipeline
 ):
-    # Assume element3 is our fidelity element
+    # Assume the third element is our fidelity element
     element_1 = config["element_1"]
     element_2 = config["element_2"]
-    element_3 = config["element_3"]
+    fidelity = config["fidelity"]
 
     # Load any saved checkpoints
     checkpoint_name = "checkpoint.pth"
-    start_element_3 = 0
+    start_fidelity = 0
 
     if previous_pipeline_directory is not None:
         # Read in state of the model after the previous fidelity rung
         checkpoint = torch.load(previous_pipeline_directory / checkpoint_name)
-        prev_element_3 = checkpoint["element_3"]
+        prev_fidelity = checkpoint["fidelity"]
     else:
-        prev_element_3 = 0
+        prev_fidelity = 0
 
-    start_element_3 += prev_element_3
+    start_fidelity += prev_fidelity
 
     loss = 0
-    for i in range(start_element_3, element_3):
+    for i in range(start_fidelity, fidelity):
         loss += element_1 - element_2
 
     torch.save(
         {
-            "element_3": element_3,
+            "fidelity": fidelity,
         },
         pipeline_directory / checkpoint_name,
     )