Instructor Karl F. Warnick Office: 459 CB

Monday Tuesday Wednesday Thursday Friday 8:00-9:00           9:00-10:00           10:00-11:00 Office 459 CB   Office 459 CB     11:00-12:00           12:00-1:00           1:00-2:00           2:00-3:25           3:25-4:40 Class 385 CB    Class 385 CB

---

Class Text
The class will be taught primarily from lecture notes.
Optional supplementary text: M. Sadiku, Numerical Techniques in Electromagnetics, 2 ed., CRC Press, 2001, or 3 ed., 2009.

Grading

Assignments: (75%)	Homework assignments will be given roughly every class period, and will be due in class the following period or as indicated. The assignments will include derivations of key results from the course material, writing numerical codes, and applying those codes to various types of application problems. Your observations and results will be used to facilitate our class discussions.
Codes: (15%)	Over the course of the semester, groups of homework assignments will lead to the development of several major codes. Successful completion of these codes will figure into the course grade. The codes and homework are substantial assignments, and take the place of midterm exams.
Final Exam (10%):	The final exam will cover important topics and derivations from the course, and will be given at the scheduled place and time as listed by the university.

Policies

Group study: I encourage working together as far as conversing about interesting points, behavior of numerical results, and interpretation of mathematical formulas. Codes must be written individually. Sharing of codes or code fragments is not allowed.

Figures: Label all plot axes including units. When comparing results, overlay them on the same plot, use a legend to identify multiple curves, and be sure that different curves are distinguishable. Use a loglog or semilog plot for numbers that become very large or very small or have a power law behavior.

Coding

Debugging even short numerical codes can take many hours. In order to reduce the time required to obtain working codes, here are several suggestions:

• One approach to coding is to sit down and start typing before you have a clear idea in your mind about how a method works. This shortcut is useful to get a quick and dirty code but increases debugging time down the road. A better way is to map out on paper how the algorithm works and derive key lines of code first. Save these notes and turn them in as documentation. Flow charts generally aren't useful, as numerical codes do not tend to have many branch points.
• Check your code against an analytical solution or a problem with a known qualititative behavior.
• The worst debugging technique is to change numbers or commands blindly and rerun the code over and over again. This is useful in rare situations such as fixing a minus sign you don't care to derive by hand, but is most often a waste of time.
• The best debugging technique is to break your code into sections and test each separately. It is extremely difficult to simultaneously debug more than one complex code segment.
• Grab a snack and let your code sit for a while, then come back and read over it slowly. Bugs will jump out at you.
• If a code is not working properly, you can often get a hint as to the cause of the problem by looking at the results for a test case. Devise simple experiments for which you know the answer, so you can localize the problem to a specific section of code.
• As a last resort, rewrite the code from scratch. This can actually be quicker than finding an obscure bug.

Good programming practices also save time in the long run:

• Do not include numerical constants such as the number of unknowns or physical dimensions multiple times in the code. Define these as variables in a parameters section at the beginning of the code.
• Use spaces around equal signs and avoid long lines.
• Creating functions for commonly used operations saves time, but with matlab, it is sometimes easier to use scripts rather than functions for main programs. This helps when debugging, because internal variables are accessible interactively when a program breaks. One a program is debugged, if you prefer to use it as a function, create a top level script which stores the function calls rather than entering them interactively.
• Comment your code. If you leave a code and return to it after a few days it may be hard to follow without comments. Describe in a few words what each variable represents and the function of each line or group of a few lines. Put in clear dividers between major code sections. Write out equations in matlab or Mathematica text notation. Document tricky minus signs and constants. Long paragraphs of descriptive prose may be unnecessary.
• Generally a given algorithm is modified and used in slightly different ways for a number of problems. You can save multiple versions of a code, but this should be done only when the code is sufficiently mature. Changing a single copy of the code is undesirable because past work is lost and must be redone if a problem is repeated. A good approach to managing multiple variations is to keep a single copy of the code and embed parameters and short sections of code for each type of problem inside if statements that can be turned on and off as needed.
• Include commands used to create and format plots at the end of a code rather than entering them interactively. To watch a computation evolve, don't plot every loop cycle, as this takes a long time, but plot every tenth or hundreth cycle.
• The matlab image and imagesc commands display arrays in the standard way with rows horizontal. However, for 2D data, it is better to have the first array index represent the x coordinate of the physical domain and the second index represent y, with the (1,1) element corresponding to the lower left corner of the physical domain. To view the data in proper orientation, rotate the array using the rot90 command before displaying using image or imagesc.