Fix compilation error docs. Add logo.

docs/Project.toml

@@ -2,4 +2,3 @@
 DataStructures = "864edb3b-99cc-5e75-8d2d-829cb0a9cfe8"
 Documenter = "e30172f5-a6a5-5a46-863b-614d45cd2de4"
 GenX = "5d317b1e-30ec-4ed6-a8ce-8d2d88d7cfac"
-Revise = "295af30f-e4ad-537b-8983-00126c2a3abe"

docs/make.jl

@@ -8,10 +8,10 @@ genx_docpath = joinpath(pwd(), "docs/src")
 push!(LOAD_PATH, genx_docpath)
 pages = OrderedDict(
     "Welcome Page" => [
-        "GenX: Introduction" => "Welcome_Page/index.md",
-        "Installation Guide" => "Welcome_Page/installation.md",
-        "Limitation of GenX" => "Welcome_Page/limitations_genx.md",
-        "Third Party Extensions" => "Welcome_Page/third_party_genx.md"
+        "GenX: Introduction" => "index.md",
+        "Installation Guide" => "installation.md",
+        "Limitation of GenX" => "limitations_genx.md",
+        "Third Party Extensions" => "third_party_genx.md"
     ],
     "Getting Started" => [
         "Running GenX" => "Getting_Started/examples_casestudies.md",
@@ -67,7 +67,7 @@ pages = OrderedDict(
             ],
             "Hydrogen Electrolyzers" => "Model_Reference/Resources/electrolyzers.md",
             "Retrofit" => "Model_Reference/Resources/retrofit.md",
-            "Resources API" => "Model_Reference/Resources/resources.md",
+            # "Resources API" => "Model_Reference/Resources/resources.md",
             "Scheduled maintenance for various resources" => "Model_Reference/Resources/maintenance.md",
             "Resource types" => "Model_Reference/Resources/resource.md"
         ],
@@ -103,7 +103,7 @@ makedocs(;
         collapselevel=1
     ),
     pages=[p for p in pages],
-    warnonly=true
+    # warnonly=true
 )
 
 # deploydocs(;

docs/src/Model_Concept_Overview/model_introduction.md

@@ -29,7 +29,7 @@ Finally, the model is usually configured to consider a full year of operating de
 With appropriate configuration of the model, GenX thus allows the user to tractably consider several interlinking decision layers in a single, monolithic optimization problem that would otherwise have been necessary to solve in different separated stages or models. The following figure reflects the range of configurations currently possible along the three key dimensions of chronological detail, operational detail, and network detail.
 
 
-![Range of configurations currently implemented in GenX along three key dimensions of model resolution](assets/Dimensions_graphic3_background.png)
+![Range of configurations currently implemented in GenX along three key dimensions of model resolution](../assets/Dimensions_graphic3_background.png)
 *Figure. Range of configurations currently implemented in GenX along three key dimensions of model resolution*
 
 The model can be configured to consider a single future planning year or multiple planning stages (or investment periods) in sequence. 

docs/src/Model_Reference/Resources/thermal.md

@@ -1,5 +1,5 @@
 # Thermal
 ```@autodocs
 Modules = [GenX]
-Pages = ["thermal.jl"]
+Pages = ["thermal.jl", "effective_capacity.jl"]
 ```

docs/src/Public_API/write_outputs.md

@@ -38,6 +38,12 @@ Modules = [GenX]
 Pages = ["write_capacity.jl"]
 ```
 
+## Write Capacity Value # TODO: add it
+```@autodocs
+Modules = [GenX]
+Pages = ["write_capacity_value.jl"]
+```
+
 ## Write Capacity Factors
 ```@autodocs
 Modules = [GenX]

docs/src/User_Guide/model_input.md

@@ -720,13 +720,13 @@ This file contains the settings parameters required to run the Method of Morris
 |policy| Name of the policy|
 
 !!! note "Notes"
-1. Upper and lower bounds are specified in terms of percentage deviation from the nominal value.
-2. Percentage variation for uncertain parameters in a given group is identical. For example, if solar cluster 1 and solar cluster 2 both belong to the ‘solar’ group, their Lower_bound and Upper_bound must be identical
-3. P\_steps should at least be = 1\%, i.e., Upper\_bound – Lower\_bound $<$ p\_steps
-4. P\_steps for parameters in one group must be identical
-5. Total\_num\_trajectory should be around 3 to 4 times the total number of uncertain parameters
-6. num\_trajectory should be approximately equal to the total number of uncertain parameters
-7. len\_design_mat should be 1.5 to 2 times the total number of uncertain parameters
-8. Higher number of num\_trajectory and len_design_mat would lead to higher accuracy
-9. Upper and lower bounds should be specified for all the resources included in the resource `.csv` file (inside the `Resource`). If a parameter related to a particular resource is not uncertain, specify upper bound = lower bound = 0.
+    1. Upper and lower bounds are specified in terms of percentage deviation from the nominal value.
+    2. Percentage variation for uncertain parameters in a given group is identical. For example, if solar cluster 1 and solar cluster 2 both belong to the ‘solar’ group, their Lower_bound and Upper_bound must be identical
+    3. P\_steps should at least be = 1\%, i.e., Upper\_bound – Lower\_bound $<$ p\_steps
+    4. P\_steps for parameters in one group must be identical
+    5. Total\_num\_trajectory should be around 3 to 4 times the total number of uncertain parameters
+    6. num\_trajectory should be approximately equal to the total number of uncertain parameters
+    7. len\_design_mat should be 1.5 to 2 times the total number of uncertain parameters
+    8. Higher number of num\_trajectory and len_design_mat would lead to higher accuracy
+    9. Upper and lower bounds should be specified for all the resources included in the resource `.csv` file (inside the `Resource`). If a parameter related to a particular resource is not uncertain, specify upper bound = lower bound = 0.
 

docs/src/User_Guide/workflow.md

@@ -29,63 +29,63 @@ The next sections in this guide provide more details on how to perform all the s
 ## Details of running a GenX case 
 This section details as to what happens in the process of running a GenX case. As a first step, the GenX package and the desired solver (is it's anyting other than the default solver, HiGHS; for instance, Gurobi) are loaded 
 
-```@example pcm
+```julia
 using GenX
 using Gurobi
 optimizer=Gurobi.Optimizer
 ```
 The next command the user needs to run is the following:
 
-```@example pcm
+```julia
 run_genx_case!("<Location_of_the_case_study_data>", optimizer)
 ```
 Contingent upon whether a single stage model or a multi-stage model is intended to be run, the above function, inturn makes calls to either of these two functions:
 For single-stage case:
-```@example pcm
+```julia
 run_genx_case_simple!(case, mysetup, optimizer)
 ```
 From within this function, if time-domain reduction (TDR) is needed, GenX first checks 	whether there already is time domain clustered data (in order to avoid duplication of efforts) by running 
-```@example pcm
+```julia
 prevent_doubled_timedomainreduction(case)
 ```
 and if the function
-```@example pcm
+```julia
 !time_domain_reduced_files_exist(TDRpath)
 ```
 returns true value, it then runs
-```@example pcm
+```julia
 cluster_inputs(case, settings_path, mysetup)
 ```
 to generate the time-domain clustered data for the time-series.
 -OR-
 For multi-stage case:
 
-```@example pcm
+```julia
 run_genx_case_multistage!(case, mysetup, optimizer)
 ```
 In this case also, the TDR clustering is done in a similar way, exxcept for the fact that if TDRSettingsDict["MultiStageConcatenate"] is set to 0, the TDR clustering is done individually for each stage. Otherwise, the clustering is done for all the stages together. The next step is configuring the solver, which is done by
-```@example pcm
+```julia
 OPTIMIZER = configure_solver(settings_path, optimizer)
 ```
 The call to configure_solver first gets the particular solver that is being used to solve the particular case at hand, which then calls a function specific to that solver in order to use either the default values of the solver settings parameter or, any other set of values, specified in the settings YAML file for that particular solver. 
 
 The configuration of solver is followed by loading the input files by running the following function:
-```@example pcm
+```julia
 myinputs = load_inputs(mysetup, case)
 ```
 The above function in its turn calls separate functions to load different resources, demand data, fuels data etc. and returns the dictionary myinputs populated by the input data. The next function call is to generate the model 
-```@example pcm
+```julia
 time_elapsed = @elapsed EP = generate_model(mysetup, myinputs, OPTIMIZER)
 println("Time elapsed for model building is")
 println(time_elapsed)
 ```
 The above function call instantiates the different decision variables, constraints, and objective function expressions from the input data. It can be seen that we also keep track of the time required to build the model. Follwoing this, the solve_model function makes the call to the solver and return the results as well as the solve time. 
-```@example pcm
+```julia
 EP, solve_time = solve_model(EP, mysetup)
 myinputs["solve_time"] = solve_time # Store the model solve time in myinputs
 ```
 For writing the results, we invoke the following function:
-```@example pcm
+```julia
 outputs_path = get_default_output_folder(case)
 elapsed_time = @elapsed outputs_path = write_outputs(EP, outputs_path, mysetup, myinputs)
 ```