Dipole Moment from constant electric field

[Click here for a PDF of this post with nicer formatting]

Question: Dipole Moment from constant electric field

In [1] it is stated that the force per unit angle on a dipole system as illustrated in Fig.1 is

where . The text was also referring to torques, and it wasn’t clear to me if the result was the torque or the force. Derive the result to resolve any doubt (in retrospect dimensional analysis would also have worked).

Fig1: Dipole moment coordinate

Answer

Let’s put the electric field in the direction (), so that the potential acting on charge is given implicitly by

or

Our positions, and velocities are

Our kinetic energy is

For our potential energies we require the component of the position vectors, which are

Our potentials are

Our system Lagrangian, after dropping the constant reference potential that doesn’t effect the dynamics is

For this problem we had two equal masses and equal magnitude charges and

Putting these together, with , we have the result stated in the text

References

[1] E.A. Jackson. Equilibrium statistical mechanics. Dover Pubns, 2000.

Stirling’s like approximation for log factorial

[Click here for a PDF of this post with nicer formatting]

Motivation

Back in my undergrad days, I rarely took notes, since most of what we covered was in the text books. The only notes I’d taken from the course where we did some thermodynamics was half an scrap paper with a simple Stirling like approximation for (sitting in my old text [1]). Here it is

Guts

First write the factorial in product form

so that it’s logarithm is a sum

We can now derivatives of both sides with respect to , ignoring the fact that is a discrete variable. For the left hand side, writing , we have

Now for the right hand side

Merging 1.2.3 and 1.2.4 into two differentials, and integrating we have

Observing that

we have

Even though we are interested in large , we note that with we have

but this is small compared to for large , so we have

Expontiating, this is

I think that our Professor’s point at the time was that when we only care about the logarithm of we can get away with 1.2.9, and can avoid the complexity and care required to do a proper Stirling’s approximation.

References

[1] C. Kittel and H. Kroemer. Thermal physics. WH Freeman, 1980.

reorganization of PHY356 (Quantum I) notes.

Looking for something in my old notes while studying for my optics exam, I found that my old phy356 notes were very disorganized.  That was my first attempt to compile my class notes into a bookish unit, and it was not done terribly well.  Here’s a reorganized version:

https://sites.google.com/site/peeterjoot/math2010/phy356.pdf

The new structure is

Basic formalism

•    Dirac Adjoint notes
•    Lecture notes: Review
•    Problems

Commutator and time evolution

•    Rotations using matrix exponentials
•    On commutation of exponentials
•    Desai Chapter II notes
•    Unitary exponential sandwich
•    Lecture notes: Review
•    Problems

Dynamical equations

•    Problems

Free particles

•    Notes for Desai chapter IV
•    Lecture notes: Review
•    Problems

Spin 1/2

•    Lecture notes: Review
•    Lecture: Orbital and Intrinsic Momentum
•    Problems

Gauge invariance, angular momentum and spin

•    Interaction with orbital angular momentum

Stern-Gerlach

•    Lecture: Stern Gerlach

Lecture: Making Sense of Quantum Mechanics

Bound state problems

•    Hydrogen like atom, and Laguerre polynomials
•    Lecture: Bound-state problems
•    Lecture: Hydrogen atom
•    Problems

Harmonic oscillator

•    Lecture: Harmonic oscillator
•    Problems

Coherent states

•    interaction with a electric field

Rotations and angular momentum

•    Lecture: Rotations and Angular Momentum
•    Notes for Desai Chapter 26

Exam prep and review

•    Questions from the Dec 2007 PHY355H1F exam
•    Questions from the Dec 2008 PHY355H1F exam
•    A problem on spherical harmonics (2010 final exam reflection)

 

Final update to course notes for Fall 2012, UofT Modern Optics (PHY485H1F), taught by Prof. Joseph H. Thywissen

As mentioned previously, I had been batching any postings of my course notes and problems from University of Toronto PHY485H1F Advanced Classical Optics, instead of posting anything individually.  This is now updated with some corrections from exam review, and two additional exam practice questions:

December 17, 2012 2010 q5 Gaussian beam problem.

December 15, 2012 Fraunhofer diffraction pattern for four circular aperatures (also from 2010 final)

 

cost of a global array access?

For an array where the value of

   myGlobalArrayOfInts[ THE_ARRAY_OFFSET_FOR_OPERATION__FOO ] == THE_VALUE_FOR_OPERATION__FOO

some developer used

   int value = THE_VALUE_FOR_OPERATION__FOO ; // for performance, just set it.

instead of

   int value = myGlobalArrayOfInts[ THE_ARRAY_OFFSET_FOR_OPERATION__FOO ]

At one point in time the assumption that myGlobalArrayOfInts[ THE_ARRAY_OFFSET_FOR_OPERATION__FOO ] was never have been any different than THE_VALUE_FOR_OPERATION__FOO was true. However, this bit of premature optimization inevitably broke when maintainance programming required that this array value be changed.

The developer fixing this asked me “How expensive is this array access”. I can’t exactly quantify the cost of this, although at least half of it in this case is probably going after the address of the global itself. On AIX I believe that this may require loading the TOC register if the last global access was in a different shared lib, and there’s probably some similar notion on most other systems. I happened to be using a Linux build at that point of time, so to help quantify the cost I took a look at the asm generated for a function of the form

int foo0()
{
   return myGlobalArrayOfInts[ THE_ARRAY_OFFSET_FOR_OPERATION__FOO ] ;
}

Here’s the code that was generated

0000000000002f50 :
    2f50:   48 8b 15 00 00 00 00    mov    0x0(%rip),%rdx        # 2f57 
    2f57:   48 63 42 14             movslq 0x14(%rdx),%rax
    2f5b:   c3                      retq

We’ve essentially got two dereferences required for this array dereference, one that’s probably getting the address of the global itself. I’d guess that this mov instruction ends up rewritten by the linker later, putting in actual values for the location of this global instead of the ’00 00 00 00′ seen in the instruction dump. Then we’ve got one more dereference to get at the global value itself.

Would this really have made a measurable difference in a function that was 841 lines of code long, (1067 straight line instruction count)? Doubtful.

C++11 play. Simple hashing, a comparison with perl

I’m very impressed with how easy C++11 makes it possible to implement a simple hash

#include <set>
#include <string>
#include <iostream>

using namespace std ;

int main()
{
   set< string > d ;

   d.insert( "uu:long" ) ;
   d.insert( "uu:long" ) ;
   d.insert( "uu:long long" ) ;

   d.insert( "qq:int" ) ;
   d.insert( "Test:int" ) ;

   for ( auto & kv : d )
   {
      cout << kv << endl ;
   }
}

If I had to do hashing like this before I’d probably have seen if I could generate a text file, and then post process it with perl, where the same hashing would look like:

#!/usr/bin/perl

my %d ;

$d{'uu:long'}++ ;
$d{'uu:long'}++ ;
$d{'uu:long long'}++ ;

$d{'qq:long'}++ ;
$d{'Test:int'}++ ;

foreach ( keys %d )
{
   print "$_\n" ;
}

Other the the header includes and namespace statement, it’s not really any harder to do this in C++ now. I just have to wait 5 years before all our product compilers catch up with the standard, I could start thinking about using this sort of code in production. Unfortunately in production I’d also have to deal with exceptions, and the (hidden) fact that the std::allocator is not generally appropriate for use within DB2 code.

Update to course notes for Fall 2012, UofT Modern Optics (PHY485H1F), taught by Prof. Joseph H. Thywissen

As mentioned previously, and originally I’m batching any postings of my course notes and problems from University of Toronto PHY485H1F Advanced Classical Optics. These are now updated with the following additional content:

December 07, 2012 Midterm review. Lloyd’s mirror

December 06, 2012 Number of photons per free space mode

December 06, 2012 Spectral line width (coherence time) of laser

December 06, 2012 Problem set. Gaussian Beams

December 02, 2012 Guoy phase shifts and higher order Gaussian modes

December 01, 2012 Fresnel form approximate solution to paraxial wave equation

November 27, 2012 Solving the homogeneous paraxial wave equation

November 23, 2012 vector identities

November 21, 2012 Planck blackbody summation

November 21, 2012 Gaussian modes

November 15, 2012 Laser pump rates

ease of getting strncat wrong.

I’d done a test build with the clang compiler of our db2 code and fired off some defects and emails to some of the code owners about messages from that compiler like:

foo.C:1220:15: warning: the value of the size argument in ‘strncat’ is too large, might lead to a buffer overflow [-Wstrncat-size]

It’s a great message, clear and unambiguous: “your code is wrong”!

Here’s a sample of the code in question that clang was complaining about:

   strncat( dirPath, ptrToDirectories, ( sizeof( dirPath ) - strlen( dirPath ) ) );

The compiler could just as well complain about simpler strncat calls.  Imagine at first that dirPath was all zeros, then the above code would be equivalent to:

   strncat( dirPath, ptrToDirectories, sizeof( dirPath ) ) ;

It’s not immediately obvious reading the strncat man page that this is wrong, since that man page says “[strncat] will use at most n characters from src”. However, it also says “As with strcat(), the resulting string in dest is always null terminated.”

Does this mean that it will use no more than n characters from src, but that it null terminates within the range of those n-characters, or does this mean use (if strlen(src) > n) n characters from src and then add a null terminator after that?

To answer that question, and rule out a possible false positive warning from the compiler I wrote the following simple bit of test code:

#include <string.h>
#include <stdio.h>

struct string
{
   char dest[2] ;
   char overflow ;
} ;

int main()
{
   string o ;
   o.dest[0] = 0  ;
   o.dest[1] = 1  ;
   o.overflow = 1 ;

   printf( "%d\n", (int)o.overflow ) ;

   strncat( o.dest, "abc", sizeof(o.dest) ) ;

   printf( "%d\n", (int)o.overflow ) ;

   return 0 ;
}

And the verdict was:

$ g++ -g t.C ; a.out
1
0

Yup, the code was bad, and the compiler is without fault. We actually have a different function for strncat’ing in our code that takes the actual buffer size, to make this harder to get wrong, but the code in question was not using that.