Skip to content
Snippets Groups Projects
Commit 914c84e1 authored by Ruth Sabariego's avatar Ruth Sabariego
Browse files

Update electromagnet.pro

parent 88f1b1c9
No related branches found
No related tags found
No related merge requests found
Pipeline #
......@@ -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.
*/
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment