| supplied, guess N+2 overwrites guess 1, and so on. You can supply  | 
  | a   | 
  | including  | 
  | merit=<expression> or  | 
  | penalty=<expression>  | 
  | in the GUESS statement. While this can save valuable time, it must  | 
  | be used with care, because POEMS will trust the value you give it. If  | 
  | the value is stale or otherwise incorrect, this will interfere with the  | 
  | optimization. If the supplied value is unrealistically poor, the  | 
  | optimizer will incorrectly tend to move away from it, good, whereas  | 
  | if it is too good, the optimizer may get stuck in that vicinity, trying  | 
  | to improve a value that is better than any available computed value.  | 
  | Syntax: GUESS <var1> = <expression> <var2> =, <expression>.... | 
  | [penalty = <expression>]  | 
LIMIT | Expression that has to be true for a valid point. Often it’s better to  | 
  | change the simulation parameters to build the limits   | 
  | replacing width with abs(width) or using more complicated  | 
  | functions of absolute values. LIMIT is better for more complicated  | 
  | functions, e.g. forcing the corners of some structure to lie within an  | 
  | arbitrary boundary. Not implemented in this release. | 
  | Syntax: LIMIT <Boolean expression>  | 
  | Example: LIMIT length*width*height ≤ MaxVolume  | 
STORE | Specify a file to store the simplex for each iteration, along with the  | 
  | corresponding penalty function values. These are in the right  | 
  | format to be cut and pasted back into the parameters file to restart  | 
  | an interation without losing previous work.  | 
  | Syntax: STORE <filename>  | 
PENALTY | 
  | 
MERIT | Defines an expression on which the optimizer is to work. Merit  | 
  | functions are maximized, and penalty functions are minimized.  | 
  | Only one of the two can be specified. In order for the optimizer to  | 
  | do anything useful, the optimization expression must depend on  | 
  | each of the optimization variables. Note that any variable  | 
  | assignment involving quantities computed by the postprocessor will  | 
  | not be updated at postprocessing time. That means that the | 
  | dependence on this iteration’s results must be included explicitly in  | 
  | <expression>. For example, if the iteration is minimizing the loss of  | 
  | a coupler, you might specify MERIT 10*log10(efficiency), which  | 
  | will work fine, but you can’t use SET dBloss=-  | 
  | 10*log10(efficiency) up in the GLOBAL section and then specify  | 
  | PENALTY dBloss in the OPTIMIZE   | 
  | up with stale data. This can sometimes be useful, but not usually.  | 
29