Rectifying spell errors

idaes_examples/notebooks/docs/unit_models/custom_unit_models/creating_unit_model.ipynb

@@ -1686,7 +1686,7 @@
    "id": "e884af34",
    "metadata": {},
    "source": [
-    "Now since there are no warnigns we can go ahead and solve the model and see if the results are optimal. "
+    "Now since there are no warnings we can go ahead and solve the model and see if the results are optimal. "
    ]
   },
   {
@@ -1784,7 +1784,7 @@
    "source": [
     "This is a good sign that the model solved optimally and a solution was found. \n",
     "\n",
-    "**NOTE:** It is a good pratice to run the model through DiagnosticsToolbox regardless of the solver termination status. \n",
+    "**NOTE:** It is a good practice to run the model through DiagnosticsToolbox regardless of the solver termination status. \n",
     "\n",
     "The next section we shall focus on testing the unit model. "
    ]
@@ -1805,7 +1805,7 @@
     "The expectation is that unit tests should be run by developers rather frequently, component tests should be run by the continuous integration system before running code, and integration tests are run across the codebase regularly, but infrequently (e.g. daily).\n",
     "\n",
     "\n",
-    "As a developer, testing is a crucial aspect of ensuring the reliability and correctness of the unit model. The testing process involves both Unit tests and Component tests, and pytest is used as the testing framework. A typical test is marked with @pytest.mark.level, where the level indicates the depth or specificity of the testing. This is written in a file usually named as test_*.py or *_test.py. The test files have functions written in them with the appropriate lavel of test being conducted.  \n",
+    "As a developer, testing is a crucial aspect of ensuring the reliability and correctness of the unit model. The testing process involves both Unit tests and Component tests, and pytest is used as the testing framework. A typical test is marked with @pytest.mark.level, where the level indicates the depth or specificity of the testing. This is written in a file usually named as test_*.py or *_test.py. The test files have functions written in them with the appropriate level of test being conducted.  \n",
     "\n",
     "For more detailed information on testing methodologies and procedures, developers are encouraged to refer to [this resource](https://idaes-pse.readthedocs.io/en/stable/reference_guides/developer/testing.html). The resource provides comprehensive guidance on the testing process and ensures that the unit model meets the required standards and functionality.\n",
     "\n",

idaes_examples/notebooks/docs/unit_models/custom_unit_models/creating_unit_model_doc.ipynb

@@ -1643,7 +1643,7 @@
       "cell_type": "markdown",
       "metadata": {},
       "source": [
-        "Now since there are no warnigns we can go ahead and solve the model and see if the results are optimal. "
+        "Now since there are no warnings we can go ahead and solve the model and see if the results are optimal. "
       ]
     },
     {
@@ -1739,7 +1739,7 @@
       "source": [
         "This is a good sign that the model solved optimally and a solution was found. \n",
         "\n",
-        "**NOTE:** It is a good pratice to run the model through DiagnosticsToolbox regardless of the solver termination status. \n",
+        "**NOTE:** It is a good practice to run the model through DiagnosticsToolbox regardless of the solver termination status. \n",
         "\n",
         "The next section we shall focus on testing the unit model. "
       ]
@@ -1759,7 +1759,7 @@
         "The expectation is that unit tests should be run by developers rather frequently, component tests should be run by the continuous integration system before running code, and integration tests are run across the codebase regularly, but infrequently (e.g. daily).\n",
         "\n",
         "\n",
-        "As a developer, testing is a crucial aspect of ensuring the reliability and correctness of the unit model. The testing process involves both Unit tests and Component tests, and pytest is used as the testing framework. A typical test is marked with @pytest.mark.level, where the level indicates the depth or specificity of the testing. This is written in a file usually named as test_*.py or *_test.py. The test files have functions written in them with the appropriate lavel of test being conducted.  \n",
+        "As a developer, testing is a crucial aspect of ensuring the reliability and correctness of the unit model. The testing process involves both Unit tests and Component tests, and pytest is used as the testing framework. A typical test is marked with @pytest.mark.level, where the level indicates the depth or specificity of the testing. This is written in a file usually named as test_*.py or *_test.py. The test files have functions written in them with the appropriate level of test being conducted.  \n",
         "\n",
         "For more detailed information on testing methodologies and procedures, developers are encouraged to refer to [this resource](https://idaes-pse.readthedocs.io/en/stable/reference_guides/developer/testing.html). The resource provides comprehensive guidance on the testing process and ensures that the unit model meets the required standards and functionality.\n",
         "\n",

idaes_examples/notebooks/docs/unit_models/custom_unit_models/creating_unit_model_test.ipynb

@@ -1643,7 +1643,7 @@
       "cell_type": "markdown",
       "metadata": {},
       "source": [
-        "Now since there are no warnigns we can go ahead and solve the model and see if the results are optimal. "
+        "Now since there are no warnings we can go ahead and solve the model and see if the results are optimal. "
       ]
     },
     {
@@ -1739,7 +1739,7 @@
       "source": [
         "This is a good sign that the model solved optimally and a solution was found. \n",
         "\n",
-        "**NOTE:** It is a good pratice to run the model through DiagnosticsToolbox regardless of the solver termination status. \n",
+        "**NOTE:** It is a good practice to run the model through DiagnosticsToolbox regardless of the solver termination status. \n",
         "\n",
         "The next section we shall focus on testing the unit model. "
       ]
@@ -1759,7 +1759,7 @@
         "The expectation is that unit tests should be run by developers rather frequently, component tests should be run by the continuous integration system before running code, and integration tests are run across the codebase regularly, but infrequently (e.g. daily).\n",
         "\n",
         "\n",
-        "As a developer, testing is a crucial aspect of ensuring the reliability and correctness of the unit model. The testing process involves both Unit tests and Component tests, and pytest is used as the testing framework. A typical test is marked with @pytest.mark.level, where the level indicates the depth or specificity of the testing. This is written in a file usually named as test_*.py or *_test.py. The test files have functions written in them with the appropriate lavel of test being conducted.  \n",
+        "As a developer, testing is a crucial aspect of ensuring the reliability and correctness of the unit model. The testing process involves both Unit tests and Component tests, and pytest is used as the testing framework. A typical test is marked with @pytest.mark.level, where the level indicates the depth or specificity of the testing. This is written in a file usually named as test_*.py or *_test.py. The test files have functions written in them with the appropriate level of test being conducted.  \n",
         "\n",
         "For more detailed information on testing methodologies and procedures, developers are encouraged to refer to [this resource](https://idaes-pse.readthedocs.io/en/stable/reference_guides/developer/testing.html). The resource provides comprehensive guidance on the testing process and ensures that the unit model meets the required standards and functionality.\n",
         "\n",

idaes_examples/notebooks/docs/unit_models/custom_unit_models/creating_unit_model_usr.ipynb

@@ -1643,7 +1643,7 @@
       "cell_type": "markdown",
       "metadata": {},
       "source": [
-        "Now since there are no warnigns we can go ahead and solve the model and see if the results are optimal. "
+        "Now since there are no warnings we can go ahead and solve the model and see if the results are optimal. "
       ]
     },
     {
@@ -1739,7 +1739,7 @@
       "source": [
         "This is a good sign that the model solved optimally and a solution was found. \n",
         "\n",
-        "**NOTE:** It is a good pratice to run the model through DiagnosticsToolbox regardless of the solver termination status. \n",
+        "**NOTE:** It is a good practice to run the model through DiagnosticsToolbox regardless of the solver termination status. \n",
         "\n",
         "The next section we shall focus on testing the unit model. "
       ]
@@ -1759,7 +1759,7 @@
         "The expectation is that unit tests should be run by developers rather frequently, component tests should be run by the continuous integration system before running code, and integration tests are run across the codebase regularly, but infrequently (e.g. daily).\n",
         "\n",
         "\n",
-        "As a developer, testing is a crucial aspect of ensuring the reliability and correctness of the unit model. The testing process involves both Unit tests and Component tests, and pytest is used as the testing framework. A typical test is marked with @pytest.mark.level, where the level indicates the depth or specificity of the testing. This is written in a file usually named as test_*.py or *_test.py. The test files have functions written in them with the appropriate lavel of test being conducted.  \n",
+        "As a developer, testing is a crucial aspect of ensuring the reliability and correctness of the unit model. The testing process involves both Unit tests and Component tests, and pytest is used as the testing framework. A typical test is marked with @pytest.mark.level, where the level indicates the depth or specificity of the testing. This is written in a file usually named as test_*.py or *_test.py. The test files have functions written in them with the appropriate level of test being conducted.  \n",
         "\n",
         "For more detailed information on testing methodologies and procedures, developers are encouraged to refer to [this resource](https://idaes-pse.readthedocs.io/en/stable/reference_guides/developer/testing.html). The resource provides comprehensive guidance on the testing process and ensures that the unit model meets the required standards and functionality.\n",
         "\n",

idaes_examples/notebooks/docs/unit_models/custom_unit_models/liquid_liquid_extractor.py

@@ -242,7 +242,7 @@ def build(self):
         self.aqueous_phase.add_geometry()
 
         # ---------------------------------------------------------------------
-        # Check flow basis is compatable
+        # Check flow basis is compatible
         t_init = self.flowsheet().time.first()
         if (
             self.aqueous_phase.properties_out[t_init].get_material_flow_basis()
@@ -308,13 +308,13 @@ def rule_material_aq_balance(self, t, j):
                 )
             elif j in self.organic_phase.properties_out.component_list:
                 # No mass transfer term
-                # Set organic flowrate to an arbitary small value
+                # Set organic flowrate to an arbitrary small value
                 return self.organic_phase.mass_transfer_term[t, "Org", j] == 0 * ounits(
                     fb
                 )
             elif j in self.aqueous_phase.properties_out.component_list:
                 # No mass transfer term
-                # Set aqueous flowrate to an arbitary small value
+                # Set aqueous flowrate to an arbitrary small value
                 return self.aqueous_phase.mass_transfer_term[t, "Aq", j] == 0 * aunits(
                     fb
                 )
@@ -334,7 +334,7 @@ def rule_material_liq_balance(self, t, j):
                 )
             else:
                 # No mass transfer term
-                # Set organic flowrate to an arbitary small value
+                # Set organic flowrate to an arbitrary small value
                 return self.organic_phase.mass_transfer_term[t, "Org", j] == 0 * aunits(
                     fb
                 )

pyproject.toml

@@ -164,7 +164,7 @@ equil = "equil"
 # Atomic elements
 Nd = "Nd"
 Ba = "Ba" # ba is also used in block names in RSOFC-SOEC example
-KNO = "KNO" 
+
 # Numpy
 arange = "arange"
 [tool.typos.default]
@@ -175,4 +175,5 @@ extend-ignore-re = [
     # as of 2024-04-25, the false positive are all due to warnings in the output of certain notebooks
     # which should be resolved regardless (see IDAES/examples#108)
     "ser[.].*",
+    "KNO[2-3]" 
 ]