Merge branch 'main' of git.gsi.de:phelix/rust/opossum

book/src/analyzers.md

 # Analyzers
 
-An analyzer is a module which "orchestrates" an optics simulation. An analyzer defines, how the model will be treated. There are basically two types of analyzers: Sequential and Non-Sequential. A sequencial analyzer traverses the graph in a defined manner and triggers the corresponding calculation defined inside the nodes. In contrast, the non-sequencial analyzer does not actually make use of the graph structure (i.e. the relations between the nodes) but only uses the nodes and their corresponding attributes such as 3D coordinates or mechanical model data.
+An analyzer is a module that "orchestrates" an optics simulation. An analyzer defines, how the model will be treated. There are basically two types of analyzers: Sequential and Non-Sequential. A sequential analyzer traverses the graph in a defined manner and triggers the corresponding calculation defined inside the nodes. In contrast, the non-sequential analyzer does not actually make use of the graph structure (i.e. the relations between the nodes) but only uses the nodes and their corresponding attributes such as 3D coordinates or mechanical model data.
 
-**Note**: The use of different analyzers might lead to ["contradicting" models](https://git.gsi.de/phelix/rust/opossum/-/issues/9). For example, one can model a free-space propagation node between two other elemenst (e.g. two lenses). It can thus define a given geometric length as attribute. On the other hand, the two lenses might have 3D coordinates with a different distance to each other than defined in the propagation node. In this case, the sequential analysis would simulate an other model situation as the non-sequential analyzer... 
+**Note**: The use of different analyzers might lead to ["contradicting" models](https://git.gsi.de/phelix/rust/opossum/-/issues/9). For example, one can model a free-space propagation node between two other elements (e.g. two lenses). It can thus define a given geometric length as an attribute. On the other hand, the two lenses might have 3D coordinates with a different distance to each other than defined in the propagation node. In this case, the sequential analysis would simulate another model situation as the non-sequential analyzer... 
 
 ## Sequential Analyzer
 
-A sequential analyzer uses the node relations defined by the edges of the model graph. It would traverse the graph from one or more sources to one or more detector nodes. While traversing, it calls the respective analysis functions of each node. The input data is taken from previously calculated light information stored in the input edges of a node. The node's analysis result will be stored an the output edges.
+A sequential analyzer uses the node relations defined by the edges of the model graph. It would traverse the graph from one or more sources to one or more detector nodes. While traversing, it calls the respective analysis functions of each node. The input data is taken from previously calculated light information stored in the input edges of a node. The node's analysis result will be stored on the output edges.
 
-The analyzer is also responsible for deciding which nodes in a graph must be calculated at all. Sometimes the user is only interested in a part of the optical network and in this case often not all nodes need to calculated at all. Furthermore, modifiactions of the model often do no need a complete recalculation of the graph but use results from earlier simulation runs. Finally, the analyzer could also decide, which nodes do not directly depend on each other. In this case, nodes can be calculated in parallel thus saving time on multi-core CPU computers.
+The analyzer is also responsible for deciding which nodes in a graph must be calculated at all. Sometimes the user is only interested in a part of the optical network and in this case, often not all nodes need to be calculated at all. Furthermore, modifications of the model often do not need a complete recalculation of the graph but use results from earlier simulation runs. Finally, the analyzer could also decide, which nodes do not directly depend on each other. In this case, nodes can be calculated in parallel thus saving time on multi-core CPU computers.
 
-There might be different analyszers available such as:
+There might be different analyzers available such as:
 
   - geometric analysis (Matrix optics)
   - Gauss mode propagation (also matrix based, see LaserCalc)
@@ -19,10 +19,10 @@ There might be different analyszers available such as:
   - ghost focus / back reflection analysis
   - ... 
 
-For each analysis, the corresponding node attributes must be set. For example, a light source node has to define a set of rays with given position and angle if a geometric analysis is performed. For wavefront propagation, a complex intensity / wavefront matrix must be defined. 
+For each analysis, the corresponding node attributes must be set. For example, a light source node has to define a set of rays with a given position and angle if a geometric analysis is performed. For wavefront propagation, a complex intensity / wavefront matrix must be defined. 
 
-**Note**: Also in this case the model might contain inconsistent values such as a wavefront which does not fit to the set of rays defined. [How do we deal with this?](https://git.gsi.de/phelix/rust/opossum/-/issues/9)
+**Note**: Also in this case the model might contain inconsistent values such as a wavefront that does not fit the set of rays defined. [How do we deal with this?](https://git.gsi.de/phelix/rust/opossum/-/issues/9)
 
 ## Non-sequential Analyzer
 
-A non-sequential analyzer does not make use of the edges for traversing the node network. This is the case for performing a free 3D raytracing analysis of an optical setup located in 3D space. Hence, for using this analyzer all nodes must have information of their location and orientation set by the respective attributes. Otherwise these nodes are simply skipped in the the simulation. One ore more light source nodes are used to cast light rays into the scene. Detectors on the other hand can collect all incoming rays for further analysis. For ray casting, each node has to have a 3D mechanical representation and a (maybe default) surface definition.
+A non-sequential analyzer does not make use of the edges for traversing the node network. This is the case for performing a free 3D raytracing analysis of an optical setup located in 3D space. Hence, for using this analyzer all nodes must have information of their location and orientation set by the respective attributes. Otherwise, these nodes are simply skipped in the simulation. One or more light source nodes are used to cast light rays into the scene. Detectors on the other hand can collect all incoming rays for further analysis. For ray casting, each node has to have a 3D mechanical representation and a (maybe default) surface definition.

book/src/architecture.md

@@ -2,12 +2,12 @@
 
 This chapter discusses the overall software structure of the OPOSSUM system.
 
-In a first version we want to concentrate on a framework providing the necessary entities (i.e. structs and traits) in order to model optical systems as [previously described](./optical_model.md). This system would simply require a `main` function calling the necessary structs. For better debugging purposes, we should already implement an export system to the `graphviz` package (dot-files) for visualization of the graph structures.
+In the first version, we want to concentrate on a framework providing the necessary entities (i.e. structs and traits) in order to model optical systems as [previously described](./optical_model.md). This system would simply require a `main` function calling the necessary structs. For better debugging purposes, we should already implement an export system to the `graphviz` package (dot-files) for visualization of the graph structures.
 
-In a further step a commandline tool should be developed accepting a data file containing the model. This requires a proper serialization / deserialization system to be implemented. For this we would propose a very well-established standard crate `serde` which can then read and write data in various formats such as JSON or YAML.
+In a further step, a command line tool should be developed to accept a data file containing the model. This requires a proper serialization / deserialization system to be implemented. For this, we would propose a very well-established standard crate `serde` which can then read and write data in various formats such as JSON or YAML.
 
-For future extensions steps, the possibilities of modular design should be investigated in detail. This approach helps keeping the basic framework simple and might improve the integration of external code contributions. Hence, the possibilities of a plugin architecture should be considered.
+For future extension steps, the possibilities of modular design should be investigated in detail. This approach helps to keep the basic framework simple and might improve the integration of external code contributions. Hence, the possibilities of a plugin architecture should be considered.
 
-A topmost level view could look like this:
+A topmost-level view could look like this:
 
 ![Toplevel architecture](./images/overall_architecture.svg)
\ No newline at end of file

book/src/edges.md

 # Edges
 
-Edges connect the nodes in the model graph. Edges contain the "light data" which needs to be exchanged between the nodes if analyzed by a [sequential analyzer](./analyzers.md#sequential-analyzer). The content of an edge depends on the type of analysis performed. For geometric optics, it contains an array of ray vectors (position & angle) together with a wavelength and an intensity. For wavefront propagation it might contain a 2D complex array representing the nearfield distribution as well as the local phase.
+Edges connect the nodes in the model graph. Edges contain the "light data" which needs to be exchanged between the nodes if analyzed by a [sequential analyzer](./analyzers.md#sequential-analyzer). The content of an edge depends on the type of analysis performed. For geometric optics, it contains an array of ray vectors (position & angle) together with a wavelength and an intensity. For wavefront propagation,, it might contain a 2D complex array representing the nearfield distribution as well as the local phase.
 
 Possible types of data:
 
   - Energy / Power flow
 
-    For simple calculation of light transmission through an optical network. This would also be a starting point for the software development. An extension could be an array of energies / powers depending on the wavelength (=spectrum). This could also propagate thorugh the network and possibly be transformed using non-linear optics (frequency doubling)
+    For simple calculation of light transmission through an optical network. This would also be a starting point for the software development. An extension could be an array of energies / powers depending on the wavelength (=spectrum). This could also propagate through the network and possibly be transformed using non-linear optics (frequency doubling)
 
   - Geometric optics propagation
 
-    In this case an array of 2D vectors representing the vertical distance from an optical axis and its angle to it. This vector might also be extended by an energy, wavelength. Later on it must be extended by the horizontal information. Furthermore, polarization information could be added using Jones matrices.
+    In this case an array of 2D vectors representing the vertical distance from an optical axis and its angle to it. This vector might also be extended by an energy, or a wavelength. Later on, it must be extended by the horizontal information. Furthermore, polarization information could be added using Jones matrices.
 
   - Wavefront optics propagation
 
-    For this kind of simulation a 2D complex matrix is necessary which simulates the nearfield intensity distribution and the local phase of the wavefront. In addition would be an array of these matrices depending on the wavelength for simulating polychromatic light. Furthermore, similar to the geometric optics case, a 2D array of local polarization information could be handled (e.g. simulation of local birefringence effects etc.).
+    For this kind of simulation, a 2D complex matrix is necessary which simulates the nearfield intensity distribution and the local phase of the wavefront. In addition, would be an array of these matrices depending on the wavelength for simulating polychromatic light. Furthermore, similar to the case of geometric optics, a 2D array of local polarization information could be handled (e.g. simulation of local birefringence effects etc.).
 
   - Time dependency
 
     It is still not clear how to [handle time-dependent phenomena](https://git.gsi.de/phelix/rust/opossum/-/issues/1)...
 
-Of course the above information can be stored simultaneously in an edge and transported through the graph.
+Of course,, the above information can be stored simultaneously in an edge and transported through the graph.
\ No newline at end of file

book/src/interfacing.md

 # Interfacing with external code
 
-The presented project is set up as a *simulation platform* which means that it only provides the framework / infrastructure to perform complex simulations of optical systems. This can be done in different ways. Once an optical system is modelled as explained before it should basically conatin all data necessary to run specific simulation codes. Besides that, the entire network can be exported to files compatible with other simulation systems. This is mostly of interest for closed-source (commercial) software packages such as ZEMAX or GLAD. Fortunately these software packages have more or less human-readable project files which can be reverse-engineered with not too much effort.
+The presented project is set up as a *simulation platform* which means that it only provides the framework / infrastructure to perform complex simulations of optical systems. This can be done in different ways. Once an optical system is modeled as explained before it should basically contain all data necessary to run specific simulation codes. Besides that, the entire network can be exported to files compatible with other simulation systems. This is mostly of interest for closed-source (commercial) software packages such as ZEMAX or GLAD. Fortunately, these software packages have more or less human-readable project files which can be reverse-engineered with not too much effort.
 
 For existing open-source software packages it is important to provide interfaces. So far, two codes could be used as proof-of-principle projects:
 
   - SHG software (GSI)
 
-    This software simulates the behaviour of non-linear crystals for second harmonic generation. This package is written in Python and could be integrated in an "SHG node". It should be investigated, how the interfacing could be performed. Some preliminary work has done in the current "play project" *opticplay*. The external code was called from rust using the PyO3 library.
+    This software simulates the behavior of non-linear crystals for second-harmonic generation. This package is written in Python and could be integrated into an "SHG node". It should be investigated, how the interfacing could be performed. Some preliminary work has been done in the current "play project" *opticplay*. The external code was called from Rust using the PyO3 library.
 
   - HASEonGPU (HZDR)
 
-    This software package is written in C++ and works on graphic CPUs (using CUDA?). If this project provides a external library (DLL) it would be relatively easy to implement. This has to be investigated.
+    This software package is written in C++ and works on graphic CPUs (using CUDA?). If this project provides an external library (DLL) it would be relatively easy to implement. This has to be investigated.
\ No newline at end of file

book/src/intro.md

-# Intröduction
+# Introduction
 
 This book represents the project documentation of OPOSSUM (**OP**en **S**ource **O**ptics **S**imulation **S**ystem and **U**nified **M**odeller). The goal of this project is the development of a common software platform for simulating various aspects of optical systems in a holistic approach. It should be particularly useful for simulating and designing large-size, high-energy / intensity laser systems.
 

book/src/materials.md

 # Using optical materials
 
-As discussed, almost all optical components (except ideal ones) consist of one or more materials. Often for simulations, several material parameters must be known. Since the same material data is shared between different nodes, an infrastructue for handling material parameters is needed. A simple approch could be a text file.
+As discussed, almost all optical components (except ideal ones) consist of one or more materials. Often for simulations, several material parameters must be known. Since the same material data is shared between different nodes, an infrastructure for handling material parameters is needed. A simple approach could be a text file.
 
-Preferable however is a database which would also allow for shared access between different users from a central server. A common materials database would thus reduce the effort for adding new materials. A draft of the database layout could be as follows:
+Preferable however is a database that would also allow for shared access between different users from a central server. A common materials database would thus reduce the effort of adding new materials. A draft of the database layout could be as follows:
 
 ![The database layout](./images/Materials%20database.png)
 
@@ -14,23 +14,23 @@ This is the central table storing the materials with their name and a reference
 
 ## Table: materialtypes
 
-This is simple table storing different material types such as "glass", "metal", "gas", "crystal" etc. The purpose is simply to provide a filter to all materials while browsing a (possible) long list of materials. Each material refers to an entry of this table. This means the material belongs to a certain material type.
+This is a simple table storing different material types such as "glass", "metal", "gas", "crystal" etc. The purpose is simply to provide a filter to all materials while browsing a (possible) long list of materials. Each material refers to an entry of this table. This means the material belongs to a certain material type.
 
 ## Table: properties
 
-This table defines the property names such as "refractive index" or "manufacturer" together with a description field. These properties are connected with one ore more data types (see next section) which represent the property value type.
+This table defines the property names such as "refractive index" or "manufacturer" together with a description field. These properties are connected with one or more data types (see next section) which represent the property value type.
 
 ## Table: datatypes
 
-The data type defines the way the value of a property is represented. This could be a value such "numeric", "string", "2dData" etc. This information defines how the actual data fields (defined in materialdata) have to be interpreted or parsed.
+The data type defines the way the value of a property is represented. This could be a value such as "numeric", "string", "2dData" etc. This information defines how the actual data fields (defined in materialdata) have to be interpreted or parsed.
 
 ## Table: datasources
 
-This table stores information about where the data was taken from (website, info from manufacturer, own measurement, etc...)
+This table stores information about where the data was taken from (website, info from the manufacturer, own measurement, etc...)
 
 ## Table: proptypes
 
-This is the connecting table for relating a given property to a set of datatypes.
+This is the connecting table for relating a given property to a set of data types.
 
 ## Table: materialdata
 
@@ -38,6 +38,6 @@ This table stores the actual material properties.
 
 # Materialdb software
 
-As a first project the materialdb software has been developed. This software consists of a [backend](https://git.gsi.de/phelix/rust/materialdb_backend) and a [frontend](https://git.gsi.de/phelix/rust/materialdb_frontend) part.
+As a first project, the materialdb software has been developed. This software consists of a [backend](https://git.gsi.de/phelix/rust/materialdb_backend) and a [frontend](https://git.gsi.de/phelix/rust/materialdb_frontend) part.
 
-The backend is written in rust using the `seaorm` package for database handling as well as the `rocket` web framework for the development of a web API. Furthermore, this crate also contains basic functions for accessing the database (read-only so far) from the node system to be devloped. For viewing / editing the database a frontend package written in Angular was developed.
+The backend is written in Rust using the `seaorm` package for database handling as well as the `rocket` web framework for the development of a web API. Furthermore, this crate also contains basic functions for accessing the database (read-only so far) from the node system to be developed. For viewing / editing the database a frontend package written in Angular was developed.
\ No newline at end of file

book/src/model_analysis.md

 # Model analysis
 
-Once a model is setup by defining the nodes, assigning specific node parameters, and connecting the nodes with edges, the model is ready to be analyzed / simulated. As already discussed in the introduction, the model could be analyzed in very different ways. One might simulate the system using geometric optics. A very simple analysis might only calculate the power / energy flow through the network. Another analysis would be a full-size Fourier optics propagation. In addition, a 3D raytracing prodcedure could give insight for illumination or straylight scenarios. 
+Once a model is set up by defining the nodes, assigning specific node parameters, and connecting the nodes with edges, the model is ready to be analyzed / simulated. As already discussed in the introduction, the model could be analyzed in very different ways. One might simulate the system using geometric optics. A very simple analysis might only calculate the power / energy flow through the network. Another analysis would be a full-size Fourier optics propagation. In addition, a 3D raytracing procedure could give insight into illumination or straylight scenarios. 
 
 Besides this "direct" simulation of the model, it is possible to simply export the model into a given format suitable for external simulation software (e.g. ZEMAX or GLAD).
 
-The underlying type of analysis fundamentally influences how to work with the model. For an energy flow or geometric analysis the system has to traverse in a particular way thorugh the network in order to stepwise calculate the light field within the edges of the model. In contrast, for a 3D raytrace analysis, the edges do not play a role at all but the nodes have to be placed at given 3D coordinates and light rays from one or more defined source nodes will be cast into the scene nad collected by detector nodes.
+The underlying type of analysis fundamentally influences how to work with the model. For an energy flow or geometric analysis the system has to traverse in a particular way through the network in order to stepwise calculate the light field within the edges of the model. In contrast, for a 3D ray-trace analysis, the edges do not play a role at all but the nodes have to be placed at given 3D coordinates and light rays from one or more defined source nodes will be cast into the scene and collected by detector nodes.
 
-For this flexibility, there are several *analyzers* provided. Note that these analyzers do not necessarily perform any calculations itself directly but might only be responsible for calling the analysis functions of the nodes. In the following we want to further discuss the analysis modes.
+For this flexibility, there are several *analyzers* provided. Note that these analyzers do not necessarily perform any calculations themselves directly but might only be responsible for calling the analysis functions of the nodes. In the following, we want to further discuss the analysis modes.
\ No newline at end of file

book/src/nodes.md

@@ -4,29 +4,29 @@ Nodes form the building blocks of the optical model. Maybe it makes sense to int
 
 1. Basic node
 
-   This node type represents lowest level modelling optical components. This category includes all ideal components such as "ideal lens", "ideal filter", "ideal mirror", etc... Furthermore it can represent an interface between tow materials such as a flat or curved surface.
+   This node type represents the lowest level modeling optical components. This category includes all ideal components such as "ideal lens", "ideal filter", "ideal mirror", etc... Furthermore, it can represent an interface between two materials such as a flat or curved surface.
 
 1. Propagation node
 
-   *This might also fall in the first category?*. This node represents a propagation though a given material. This includes free-space propagation (eg. in air or vaccum).
+   *This might also fall in the first category?*. This node represents propagation through a given material. This includes free-space propagation (eg. in air or vacuum).
 
-1. Sequencial group node
+1. Sequential group node
 
-   A sequencial group node contains a nested directed graph of basic, propagation or other group nodes. A real lens could be a group node consisting of a (curved) input surface node, a propagation node (inside of the lens), and an exit surface.
+   A sequential group node contains a nested directed graph of basic, propagation or other group nodes. A real lens could be a group node consisting of a (curved) input surface node, a propagation node (inside of the lens), and an exit surface.
 
-1. Non-sequencial group node
+1. Non-sequential group node
 
-   A non-sequenctial group contains other nodes (which might be still be set up as a graph but do not use the structure) which are simply placed in 3D space. This could be used for simulating a flashlamp-pumped systems which need the illumination of a laser rod to be simulated. *On has to think about the definition of input and output ports (see later) for these systems.* 
+   A non-sequential group contains other nodes (which might still be set up as a graph but do not use the structure) which are simply placed in 3D space. This could be used for simulating flashlamp-pumped systems which need the illumination of a laser rod to be simulated. *One has to think about the definition of input and output ports (see later) for these systems.* 
 
 1. Reference node
 
-   This node type represents a link to another node. It could be necessary to use reference nodes while modelling loops such as [resonators](optical_model.md#loops-for-modelling-resonators).
+   This node type represents a link to another node. It could be necessary to use reference nodes while modeling loops such as [resonators](optical_model.md#loops-for-modelling-resonators).
 
-**Note:** It might be necessary to propagate through a node in a reverse direction (e.g. for back reflection / ghost focus analysis). Hence each node should have a "reverse" function. In case of a propagation node this would be identical. For a baisc node it might change the sign of some properties such as the radius of curvature. For group nodes the underlying order of sub-nodes have to be reversed. The reference node only needs a qualifier to denote wether the propagation os reversed or not.
+**Note:** It might be necessary to propagate through a node in a reverse direction (e.g. for back reflection / ghost-focus analysis). Hence each node should have a "reverse" function. In the case of a propagation node, this would be identical. For a basic node, it might change the sign of some properties such as the radius of curvature. For group nodes, the underlying order of sub-nodes has to be reversed. The reference node only needs a qualifier to denote whether the propagation is reversed or not.
 
 ## Ports
 
-Ports are the connector points between nodes and can be connected by [edges](edges.md). Ports are strictly distinguished as "input" and "ouput" ports. Output ports can only be connected to input ports of another node and vice versa while it is forbidden to connect two input or two output ports. In addition, output ports do not need to be connected to other nodes. During analysis, any result will be simply discarded.
+Ports are the connector points between nodes and can be connected by [edges](edges.md). Ports are strictly distinguished as "input" and "output" ports. Output ports can only be connected to input ports of another node and vice versa while it is forbidden to connect two input or two output ports. In addition, output ports do not need to be connected to other nodes. During analysis, any result will be simply discarded.
 
 Ports have a specific name in order to distinguish them. For example, a beamsplitter cube might have one input port (e.g. named "input") and two output ports named "reflected" and "transmitted" for the two outgoing beams.
 
@@ -34,34 +34,34 @@ Nodes with output ports only form the optical sources while nodes containing (us
 
 ## Attributes
 
-Each node can have a set of attributes which represent its specific properties. For example, a propagation node contains a propagation length and a material. An ideal lens contains the focal length as attribute. Each attribute has a name and a strictly defined data type. Attributes may have default values or are completely optional.
+Each node can have a set of attributes that represent its specific properties. For example, a propagation node contains a propagation length and a material. An ideal lens contains the focal length as an attribute. Each attribute has a name and a strictly defined data type. Attributes may have default values or are completely optional.
 
-In addition, nodes have a set of attributes which are common to all of them. However, all of these attributes are optional (e.g. can be "empty").
+In addition, nodes have a set of attributes that are common to all of them. However, all of these attributes are optional (e.g. can be "empty").
 
 ### Common attributes for all nodes
 
 1. Node type
 
-   This defines node model such as basic node types (propagation, ideal lens, ideal filter etc..) as well as the type sequential / non-sequencial group node. Maybe this is not stricly an attribute but a given rust struct type.
+   This defines node model such as basic node types (propagation, ideal lens, ideal filter etc..) as well as the type sequential / non-sequential group node. Maybe this is not strictly an attribute but a given rust struct type.
 
 1. Node name
 
-    While not strictly necessary it is strongly recommended to assign a name to a node for easier identification. In principle different nodes can have the same name but this might cause many confusions. Internally the model uses unique IDs for each node in order to distinguish them but these IDs are only internally handled.
+    While not strictly necessary it is strongly recommended to assign a name to a node for easier identification. In principle, different nodes can have the same name but this might cause much confusion. Internally the model uses unique IDs for each node in order to distinguish them but these IDs are only internally handled.
 
 1. Component Database ID (optional)
 
-   If set, this could be a reference to a (local) component database. It should be considered to also include the database information while exporting the model to a file. If thie ID is not set, it would be a "manually configured" component.
+   If set, this could be a reference to a (local) component database. It should be considered to also include the database information while exporting the model to a file. If the ID is not set, it would be a "manually configured" component.
 
 1. Material
 
-   *This is stricly necessary only for propagation nodes...*
-   Each optical element consists of a given material. These are mostly differenct glass materials but could also be metals (i.e. for mirrors) or other substances. Even for free-space propagation nodes a material must be given. This might often be "air" or "vacuum". Since materials have a plethora of attributes and will be used by different nodes within a model, the material will be a reference pointing to a materials database.
+   *This is strictly necessary only for propagation nodes...*
+   Each optical element consists of a given material. These are mostly different glass materials but could also be metals (i.e. for mirrors) or other substances. Even for free-space propagation nodes a material must be given. This might often be "air" or "vacuum". Since materials have a plethora of attributes and will be used by different nodes within a model, the material will be a reference pointing to a materials database.
 
-   **Note**: For interoperatibility, it might not be always a good idea to only have the material properties in a (local) database. If the model data is given to another user, this data might not be found in his (also local) database. Hence it should be possible to attach the actual material data to the model during export. The alternative would be to have a global database...    
+   **Note**: For interoperability, it might not be always a good idea to only have the material properties in a (local) database. If the model data is given to another user, this data might not be found in his (also local) database. Hence it should be possible to attach the actual material data to the model during export. The alternative would be to have a global database...    
 
 1. 3D location
 
-   Each node can have an information about its location in 3D space determined as XYZ coordinates with respect to a given global origin. The achor position of the node depends on the specific node type. This attribute together with the orientation information (see next point) can be used for doing a 3D raytrace analysis or simply for visualization.
+   Each node can have information about its location in 3D space determined as XYZ coordinates with respect to a given global origin. The anchor position of the node depends on the specific node type. This attribute together with the orientation information (see next point) can be used for doing a 3D ray-trace analysis or simply for visualization.
 
 1. 3D orientation
 
@@ -69,18 +69,18 @@ In addition, nodes have a set of attributes which are common to all of them. How
 
 1. Aperture shape
 
-   Each real world optical component has a limited physical / meachnical size which also determines the area of incoming light it can handle. Incoming beams farther away from the optical axis than the component's extent will simply be lost during the analysis. Hence, each node can define an aperture with different shapes (mostly circular or rectangular). The exact handling of the aperture is defined by the specific node. Without a given aperture many nodes assume an infinintely large component such that all beam are always catched.
+   Each real-world optical component has a limited physical / mechanical size which also determines the area of incoming light it can handle. Incoming beams farther away from the optical axis than the component's extent will simply be lost during the analysis. Hence, each node can define an aperture with different shapes (mostly circular or rectangular). The exact handling of the aperture is defined by the specific node. Without a given aperture many nodes assume an infinitely large component such that all beams are always caught.
    
-   **Note**: It might be necessary to extent this to one aperture per input port for asymmetric parts.
+   **Note**: It might be necessary to extend this to one aperture per input port for asymmetric parts.
 
 1. 3D mechanical model
 
-   For non-sequential analysis (e.g. ray tracing), a 3D geometric model is necessary. This could be provided a static 3D files (OBJ, STL, etc.) or programmatically derived. For example, the model of a spherical lens could be directly calculated.
+   For non-sequential analysis (e.g. ray tracing), a 3D geometric model is necessary. This could be provided as static 3D files (OBJ, STL, etc.) or programmatically derived. For example, the model of a spherical lens could be directly calculated.
 
 1. Surface definitions
 
-   For both, sequential and non-sequential analysis, surface properties such as coating or roughness which define the way light will be reflected or propagate through should be defined. *This could also be modelled using basic nodes*
+   For both, sequential and non-sequential analysis, surface properties such as coating or roughness which define the way light will be reflected or propagated through should be defined. *This could also be modeled using basic nodes*
 
 ## Analysis interface
 
-As discused, the actual calculation is performed by the nodes. The presented framework will only make sure that all necessary input data will be provided. For this, each node has to implement an Analysis function with light data from the incoming edges as parameters. This function can now either directly perform a calculation or call specific external modules (such as C/C++ library code or a python script)
+As discussed, the actual calculation is performed by the nodes. The presented framework will only make sure that all necessary input data will be provided. For this, each node has to implement an Analysis function with light data from the incoming edges as parameters. This function can now either directly perform a calculation or call specific external modules (such as C/C++ library code or a Python script)
\ No newline at end of file