diff --git a/Magnetostatics/electromagnet.pro b/Magnetostatics/electromagnet.pro
index 066ada9edb5cae64c536067f1433c678e26d1453..4261455468d6a29f9867713205cf8285d2d48b20 100644
--- a/Magnetostatics/electromagnet.pro
+++ b/Magnetostatics/electromagnet.pro
@@ -29,20 +29,19 @@
    the reluctivity.
 
    Electromagnetic fields expand to infinity. The corresponding boundary
-   condition can be imposed rigorously by means of a gometrical transformation
+   condition can be imposed rigorously by means of a geometrical transformation
    that maps a ring (or shell) of finite elements to the complementary of its
    interior.  As this is a mere geometric transformation, it is enough in the
    model description to attribute a special Jacobian to the ring region
    ("AirInf") - see the "Jacobian" section below.  With this information, GetDP
-   is able to deal with the correct transformation of all quantities involved in
-   the model.
+   is able to correctly transform all quantities involved in the model.
 
    The special Jacobian "VolSphShell" takes 2 parameters in this case,
    "Val_Rint" and "Val_Rext", which represent the inner and outer radii of the
-   transformed ring region and whose value must match those used in the
+   transformed ring region and the value of which must match those used in the
    geometrical description of the model (.geo file).  This is a typical case
    where Gmsh and GetDP must consistently share parameter values.  To ensure
-   consistency in all cases, common parameters are defined is a specific file
+   consistency, common parameters are defined is a specific file
    "electromagnet_common.pro", which is included in both the .geo and .pro file
    of the model.
 
@@ -72,8 +71,8 @@ Group {
 
      The abstract regions in this model have the following interpretation:
      - Vol_Mag     : full volume domain
-     - Vol_S_Mag   : region where the current source js is defined
-     - Vol_Inf_Mag : region where the infinite ring geometric transformation is applied
+     - Vol_S_Mag   : region with imposed current source js
+     - Vol_Inf_Mag : region where the infinite ring geometric transformation applies
      - Sur_Dir_Mag : part of the boundary with homogenous Dirichlet conditions
      - Sur_Neu_Mag : part of the boundary with non-homogeneous Neumann conditions
   */
@@ -85,7 +84,7 @@ Group {
 }
 
 /* The weak formulation for this problem is derived in a similar way to the
-   electrostatic weak formulation from Tutorial 1. The main difference is that
+   electrostatic weak formulation from Tutorial 1. The main differences are that
    the fields are now vector-valued, and that we have one linear (source) term
    in addition to the bilinear term. The weak formulation reads: find a such
    that
@@ -109,13 +108,13 @@ Group {
 Function {
   mu0 = 4.e-7 * Pi;
 
-  /* New ONELAB variables can then be defined using defineNumber, e.g.: */
+  /* New ONELAB variables can then be defined using DefineNumber, e.g.: */
   murCore = DefineNumber[100, Name "Model parameters/Mur core",
 			 Help "Magnetic relative permeability of Core"];
 
   /* When the script is run, if the parameter named "Model parameters/Mur core"
      has not been previously defined, it takes the value (100) provided in
-     defineNumber and is sent to the ONELAB server. The "/" character in the
+     DefineNumber and is sent to the ONELAB server. The "/" character in the
      variable name is interpreted as a path separator, and results in the
      creation of a sub-tree in the graphical user interface. If the script is
      re-run later, the value will be updated using the value from the server
@@ -150,7 +149,7 @@ Constraint {
 }
 
 /* In the 2D approximation, the magnetic vector potential a and the current
-   density js are vectors with a z-component only, i.e.:
+   density js are vectors with only the z-component, i.e.:
 
    a  = Vector [ 0, 0, az(x,y) ]
    js = Vector [ 0, 0, jsz(x,y) ]
@@ -162,7 +161,7 @@ Constraint {
    with "BF_PerpendicularEdge" basis functions associated to nodes of the mesh)
    and in the "Hregion_j_Mag_2D" FunctionSpace for js ("Vector" with
    "BF_RegionZ" basis functions associated with the region Vol_S_Mag). Without
-   giving all the details, a is thus node-based, whereas js is region-wise
+   providing explicit details, a is thus node-based, whereas js is region-wise
    constant. */
 
 Group {
@@ -232,7 +231,7 @@ Integration {
    Integral { [ - Dof{js} , {a} ];
      In Vol_S_Mag; Jacobian Vol; Integration Int; }
 
-   The chosen implementation below is however more effeicient as it avoids
+   The chosen implementation below is however more efficient as it avoids
    evaluating repeatedly the function js_fct[] during assembly.
 */