-fdtd/-windowwake: Wakepotential in a moving computational window

 ##############################################################################
 # Flags: nomenu, noprompt, nomessage,                                        #
 ##############################################################################
 # section: -windowwake                                                       #
 ##############################################################################
 # strangsplitting= yes                                                       #
 # periodic  = no                 -- Assume periodic geometry.                #
 #    nperiods=   100             -- Maximum number of periods to consider.   #
 #    modstore=    10             -- Store wakepotentials after simulating    #
 #                                --   multiples of modstore*(pzhigh-pzlow).  #
 # __xpartition= no               -- PVM/MPI: enforce partitioning in x only. #
 ##############################################################################
 # doit, ?, return, help                                                      #
 ##############################################################################

• strangsplitting:
  Possible values are "yes, no".
  If strangsplitting=yes, a scheme with splitted updates for the z-transverse components and z-longitudinal components is used. This scheme has negligible dispersion error for TEM-waves propagating in z-direction.
• periodic:
  Possible values are "yes, no".
  If periodic= no, the length of the geometry as specified via
  -mesh, pzlow= ZLOW, pzhigh= ZHIGH is used for computing the wakepotential.
  If periodic= yes, the length of the geometry as specified via
  -mesh, pzlow= ZLOW, pzhigh= ZHIGH is assumed to be one period of a finite periodic structure with number of periods given by nperiods= NP. After computing the fields in a multiple of modstore= MP periods, the wakepotentials so far are recorded to the database.
• nperiods= NP:
  Number of periods to compute when periodic=yes.
• modstore= MP:
  At which periods to store the intermediate results.

Note: The parameters of the exciting linecharge are taken from the section -lcharge. The moving computational window has a length of isigma*sigma + shigh. The grid-spacing in z is the minimum of all the x-spacings and y-spacings and, if the specified "zspacing" in section "-mesh" is smaller, then that zspacing is used.

Napoly-like integration is performed, and cannot be switched off.

The memory requirement is proportional to the length of the moving computational window, ie proportional to isigma*sigma + shigh. One should not specify a large value for shigh, in particular not longer than the structure length, otherwise a conventional wakepotential computation is more economic.

The CPU requirement is proportional to the length of the moving window times the length over which the moving window must travel. That length is the z-extension of the structure plus the length of the window. The CPU requirement is proportional to (isigma*sigma + shigh) * (pzhigh-pzlow + isigma*sigma + shigh). Any specified port is ignored. The x- and y-extension of the computational volume must be specified large enough that reflections from the x- and y-borders cannot change the wakepotentials. Eg. waveguides going in x- or y-direction should be modeled with a length of "shigh".

Lossy dielectrics are ignored.

Only fields specified via fexport will be exported.

The only other result is the wakepotential.

Example The following specifies that we want to compute the wakepotential of a linecharge traveling with the speed of light along the axis (x,y)=(0,0). The total charge of the line-charge shall be 1 pC, and its gaussian width sigma shall be 1 mm. We are interested in s-values up to 20 mm.

 -lcharge
    xpos= 0, ypos= 0
    charge= 1e-12
    sigma= 1e-3
    shigh= 20e-3
 -windowwake
    doit