<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font face="Times New Roman, Times, serif">Hello Profs Christophe
      Geuzaine and Jean-François Remacle, or others<br>
      <br>
      I have been experimenting with gmsh-getdp electromagnetic
      simulation, focusing on magnetostatic cases involving 3D
      solenoidal inductors with permeable cores. Overall, I am greatly
      impressed with gmsh/getdp's capabilities and organization, but I
      have run into some difficulties I can't seem to get past. <br>
      <br>
      My objective is to design a complicated magnetic flux collector
      for an alternating magnetic field sensor in a borehole. I am
      working only with your compiled software, as I am not a C
      programmer. Since there is no built-in provision in gmsh-getdp for
      creating an external (uniform) field and observing the voltage it
      induces in the solenoid, I have been trying to do the inverse EM
      problem of finding the distant b magnetic field generated by
      current in the inductor (as modified by the core).<br>
      <br>
      <b>Problem 1</b>     I can run your Inductor (3d) model with no
      difficulty, and also a very simple test model (SensTest) of a
      cylindrical inductor with cylindrical core.  However, when I have
      tried to incorporate a more complicated flux collector system (my
      model sensor), the model seems to mesh and display properly, but
      getdp provides a physically wrong source current <i>js</i> even
      though <i>js0</i> is correct. <br>
      <br>
      Although the stranded inductor current density <i>js0</i> is
      (correctly) a simple, unidirectional, cylindrical current, </font><font
      face="Times New Roman, Times, serif"><font face="Times New Roman,
        Times, serif">along the inner boundary of the inductor, </font>the <i>
        js</i> derived from it is directed in the correct annular
      direction but flows in the wrong (opposite) direction in all outer
      parts of the inductor. The resulting b field seems correct for
      this<i> js</i>, but it is incorrect for the provided <i>js0</i>.<br>
      <br>
      I have likely caused this problem by some misunderstanding or
      simple coding error; but I cannot find the bug</font><font
      face="Times New Roman, Times, serif"><font face="Times New Roman,
        Times, serif"> after many hours of experimenting</font>. Can you
      give me any suggestions?<br>
      <br>
      <b>Problem 2</b>  In both sensor and senstest, I have used the
      spherical extension to infinity </font><font face="Times New
      Roman, Times, serif"><font face="Times New Roman, Times, serif">of
        the external field </font>that is employed in your Inductor
      example. I have no difficult in displaying the vector field using
      your graphics GUI, but I want quantitatively </font><font
      face="Times New Roman, Times, serif"><font face="Times New Roman,
        Times, serif">to </font>analyze the b vector flux density near
      the radius of the inner sphere. I can read the <i>_.res</i>, <i>_.pre</i>
      and <i>_.pos</i> output files in Matlab, but have had difficulty
      interpreting the vector components in the file; especially in
      relating them exactly to what I see in the gmsh GUI vector plots
      and to the mesh nodal coordinates. Are the gmsh-plotted vectors
      already interpolated from the edge element values of <b>A</b>
      onto a different grid?  The GUI b vector plots seem to provide one
      vector per tetrahedron, (as best I can tell), but the data output
      file<i> b.pos</i> etc., provides 6 components per tetrahedron,
      suggesting something different.<br>
      <br>
      Can you direct me to any documentation about how to relate the
      field values </font><font face="Times New Roman, Times, serif"><font
        face="Times New Roman, Times, serif">in <i>b.pos</i> </font>to
      the mesh node location for the EM case where edge elements are
      employed in the analysis.<br>
      <br>
      I feel badly asking for this much support from a freeware
      provider. If what I am asking is too onerous, I might be able to
      provide modest remuneration to a person, or make a contribution to
      an organization for this effort. Please don't hesitate to ask.<br>
      <br>
      I append the file tree I have used with gmsh-getdp. I have worked
      with versions 2.14 to 2.16.<br>
      <br>
      With sincere thanks<br>
      <br>
      Gordon West <br>
      Retired Prof of Physics (geophysics), Univ of Toronto<br>
      Consulting geophysicist<br>
      <br>
      <br>
      <br>
      <br>
    </font>
  </body>
</html>