[Getdp] Specifying a detailed charge distribution: what's the best way?

John_V jvillar.john at gmail.com
Thu Sep 9 16:00:52 CEST 2010


Thanks for your reply, Michael.

I took some time to study the examples you mentioned, but these differ from
my problem in this respect:

In the examples, the first problem is calculated within GetDP, which
therefore has the solution available to it.

In my case, the first problem is solved by a program I have written. (The
finite element method is not used, so GetDP is not applicable.)
Consequently, GetDP does not already know about this solution. It must
somehow be told. The question is how.

By analogy with the provided examples I expect my formulation to look like
this:

Formulation {
  { Name Electrostatics_v; Type FemEquation;
    Quantity {
      { Name v; Type Local; NameOfSpace Hgrad_v_Ele; }
    }
    Equation {
      Galerkin { [ epsr[] * Dof{d v} , {d v} ]; In DomainCC_Ele;
                 Jacobian Vol; Integration GradGrad; }
      Galerkin { [ -rho[]/eps0 , {v} ]; In SourceDomain;
                 Jacobian Vol; Integration GradGrad; }
    }
  }
}

In this formulation, rho[] is a piecewise function. How do I import its
definition into my GetDP solution? Some possibilities:

Possibility #1: The examples show definition of a piecewise function within
the problem definition files with such syntax as

Function {

  /* The relative permittivity (needed in the formulation) is piecewise
     defined in elementary groups */

  epsr[Vacuum] = 1.;
  epsr[Lines] = 3.5.;
  epsr[SourceDomain] = 3.5;

  /* Charge densities in appropriate regions are set here */
  rho[PosLayer] =  1.60218e8;
  rho[NegLayer] = -1.60218e8;

}

I could have my program insert thousands of such lines in the problem
definition file. However, in these examples the argument of rho[arg]
references the GEOMETRY. (I.e., rho[] in physical volume #100 is some
constant value.) I need a way to define rho[] with respect to the MESH.
(I.e., My program tells me rho1 in mesh element 1, rho2 in mesh element 2,
etc., repeated in principle for all mesh elements. --rho[] in most mesh
elements will be 0, but I expect thousands or tens of thousands of mesh
elements with nonzero charge density). Is there a syntax that allows
replacement of the various geometrical region references in these
definitions with references to the mesh regions?

Or Possibility #2: Can I have my program write the 1st problem solution for
rho[] to a file that GetDP imports? If so, where do I learn the correct file
format I should use and the syntax for importing a piecewise function from a
file?

Or Possibility #3: It strikes me that my rho[] solution is a lot like a
field rather than a function, inasmuch as both my rho[] and fields are
defined on the mesh. But if rho is a field it is different from the examples
I have seen in that it is defined on the volume elements, not on the nodes
or edges. Is there such a creature in GetDP? If so, is there a way to import
it from a file?

John


On Tue, Sep 7, 2010 at 7:28 AM, <michael.asam at infineon.com> wrote:

> Hi John,
>
> as far as I understand you want to calculate a 1st problem and
> use this result (the charge density) in a 2nd problem.
> There are two examples according this topic in the wiki:
> ChainedResolution and PreResolution
> Here is explained how to use a result calculated previously
> in a consecutive simulation.
> Maybe they will help you solving your problem.
>
> Best regards
> Michael
>
>
> Message: 1
> Date: Thu, 2 Sep 2010 11:31:48 -0400
> From: John_V <jvillar.john at gmail.com>
> Subject: [Getdp] Specifying a detailed charge distribution: what's the
>        best    way?
> To: getdp at geuz.org
> Message-ID:
>        <AANLkTi=BSHZZrsjW0VasYN+u8BsxVkmFQoxijWXdH59J at mail.gmail.com<BSHZZrsjW0VasYN%2Bu8BsxVkmFQoxijWXdH59J at mail.gmail.com>
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Must GetDP functions be specified only by using the mesh file's region
> number (the first of the tags given for each mesh element in the mesh
> file)?
> Or is it also possible to specify a function by reference to other tags or
> even the element number?
>
> I ask because in my problem I do not know the charge distribution at the
> time I mesh the geometry. What I want to do is this:
>
>   1. Mesh my geometry
>   2. Use the mesh as input to an independent calculation that determines
>   the charge density that results from exposure of this sample to a beam of
>   charged particles. (The charge density will be approximated as the total
>   charge within each mesh element divided by that element's volume.)
>   3. Write GetDP's .pro file, including its definition of the "rho"
>   function that defines the charge density.
>   4. Run GetDP to solve for the potentials.
>
> The problem, as you can see, is that when the mesher assigns region numbers
> in step 1 it must so so without knowledge of the charge distribution, since
> the latter is not determined until step 2.
>
> If necessary, I can have my step 2 calculation include rewriting the mesh
> file with each mesh element, or at least those with non-zero charge,
> assigned a unique region number. That is what I am presently thinking I
> will
> need to do. --But this unnecessarily makes other function definitions more
> of a kludge. (Imagine I have a geometric region that is all the same
> dielectric constant but is divided into thousands of mesh elements each
> with
> different charge density. Possibly there is no escaping having thousands of
> rho[regionxxx] = *.*** lines in the .pro file, but must there also be a
> separate thousands of epsr[regionxxx] = sameDielectricConstantValue lines
> for the permittivity definition?) Is there a better way?
>
> John
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.geuz.org/pipermail/getdp/attachments/20100902/4135c4bb/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> getdp mailing list
> getdp at geuz.org
> http://www.geuz.org/mailman/listinfo/getdp
>
>
> End of getdp Digest, Vol 90, Issue 2
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.geuz.org/pipermail/getdp/attachments/20100909/670d6ab5/attachment.html>