--- a/src/BoundaryConditions/BoundaryConditions.jl	Sun May 26 18:19:02 2024 -0700
+++ b/src/BoundaryConditions/BoundaryConditions.jl	Wed May 29 22:35:08 2024 +0200
@@ -1,10 +1,11 @@
 module BoundaryConditions
 
+# REVIEW: Does this need to be in a separate module? I feel like it fits quite well into SbpOperators.
 
 export BoundaryCondition
 export discretize_data
-export data
-export id
+export data # REVIEW: Name too generic to export.
+export id # REVIEW: Also to generic. Change to `boundary`?
 
 export NeumannCondition
 export DirichletCondition

--- a/src/BoundaryConditions/boundary_condition.jl	Sun May 26 18:19:02 2024 -0700
+++ b/src/BoundaryConditions/boundary_condition.jl	Wed May 29 22:35:08 2024 +0200
@@ -4,7 +4,7 @@
 A type for implementing data needed in order to impose a boundary condition.
 Subtypes refer to perticular types of boundary conditions, e.g. Neumann conditions.
 """
-abstract type BoundaryCondition{T1,T2} end
+abstract type BoundaryCondition{T1,T2} end # REVIEW: No type parameters needed here.
 
 """
     id(::BoundaryCondition)
@@ -33,14 +33,14 @@
 
 struct DirichletCondition{T1,T2} <: BoundaryCondition{T1,T2}
     data::T1
-    id::T2
+    id::T2 # REVIEW: This field not needed since BoundaryId are usually type parameters?
 end
 id(bc::DirichletCondition) = bc.id
 data(bc::DirichletCondition) = bc.data
 
 struct NeumannCondition{T1,T2} <: BoundaryCondition{T1,T2}
     data::T1
-    id::T2
+    id::T2 # REVIEW: This field not needed since BoundaryId are usually type parameters?
 end
 id(bc::NeumannCondition) = bc.id
 data(bc::NeumannCondition) = bc.data

--- a/src/BoundaryConditions/sat.jl	Sun May 26 18:19:02 2024 -0700
+++ b/src/BoundaryConditions/sat.jl	Wed May 29 22:35:08 2024 +0200
@@ -8,6 +8,7 @@
 is the boundary data.
 """
 function sat_tensors end
+# REVIEW: Rename `sat_op` to `penalty_tensor`?
 
 
 """
@@ -21,4 +22,4 @@
 function sat(op, grid, bc::BoundaryCondition, params...)
     sat_op, L = sat_tensors(op, grid, bc, params...)
     return SAT(u, g) = sat_op*(L*u - g)
-end
\ No newline at end of file
+end

--- a/src/Grids/tensor_grid.jl	Sun May 26 18:19:02 2024 -0700
+++ b/src/Grids/tensor_grid.jl	Wed May 29 22:35:08 2024 +0200
@@ -95,7 +95,7 @@
     return LazyTensors.concatenate_tuples(b_ind...)
 end
 
-orthogonal_grid(g::TensorGrid, id::BoundaryIdentifier) = g.grids[grid_id(id)]
+orthogonal_grid(g::TensorGrid, id::BoundaryIdentifier) = g.grids[grid_id(id)] # REVIEW: Seems clearer to me to just inline this and remove the function definition?
 
 
 function combined_coordinate_vector_type(coordinate_types...)

--- a/src/SbpOperators/volumeops/laplace/laplace.jl	Sun May 26 18:19:02 2024 -0700
+++ b/src/SbpOperators/volumeops/laplace/laplace.jl	Wed May 29 22:35:08 2024 +0200
@@ -105,4 +105,4 @@
     return B
 end
 
-positivity_properties(Δ::Laplace) = parse_named_tuple(Δ.stencil_set["Positivity"]["D2"])
\ No newline at end of file
+positivity_properties(Δ::Laplace) = parse_named_tuple(Δ.stencil_set["Positivity"]["D2"]) # REVIEW: Can this function extract theta_H from the inner product instead of storing it twice in the TOML?