Consider that atoms are approximately 99.99% nothing, you are current determining the kinetics of approximately nothing. Congratulations.

@red

Is this all done assuming purely Classical interactions, or is there a Quantum component?

bo_sox, why are you the way that you are? Honestly, every time someone tries to do something fun or exciting, you make it not that way. I hate so much about the things that you choose to be.

@bo_sox
Consider that atoms are approximately 99.99% nothing, your brain content is approximately nothing. You still managed to produce a sentence vaguely related to what's going on here: congratulations.

@abge
They certainly have a quantum component. Basically once you established the mathematics best describing your kinetics results and the mechanism that goes with these kinetics (or vice versa), you enter the realm of quantum chemistry immediately.
Quantum chemistry relies on several founding principles. The first is that the moment you have more than one electron in your system, which is obviously the case for most chemical systems, you will need to rely on approximations to find the electronic wave function and/or electronic properties. The two guiding principles of obtaining the correct electronic wave function for a multi-electron molecule are the Aufbau principle and the variational principle
http://en.wikipedia.org/wiki/Aufbau_principle
http://en.wikipedia.org/wiki/Variational_method
Perhaps I'll put some more stuff here later if people want to know a little more, although it's a very vast domain and I'm really taking shortcuts and taking a rather random starting point for discussion :D

@dub
Indeed.

You're right, red. My brain and my entire existence is 99.99% nothing.

@red

So, are your approximations based on the Born-Oppenheimer approximation?

I am somewhat familiar with Hartree-Fock, which I believe is a Variational method, although all of my work was done with Density Functional Theory.

What is the application for this?

The Born Oppenheimer approximation, that I also use, is one of the most powerful tools in quantum chemistry. It states that the mass of an electron is so much smaller than the mass of nucleons, that the location of the nuclei determine the chemical system entirely.

Actually a variational principle was developed for DFT as well, that works pretty much the same way as it does for HF. DFT has won terrain ever since its development in the 1960s and is now the default method for calculating chemical systems. Particularly the scaling rules with size (number of atoms) for DFT make it an attractive approach for larger systems.

@red

So, you're trying to calculate the Wavefunction as a function of time, yes?

Not if I can use the BOA to avoid it ;-)

Well, clearly not the *true* wavefunction. But the approximate wavefunction? Or are you calculating something less specific?

DFT doesn't rely very heavily on wavefunctions, calculating the electronic density yields the electronic wavefunctions as a side product almost. Basically wavefunctions in the DFT formalism are just the mathematical building blocks to design a good density, but don't take on much significance other than that. It's one of the funnier aspects of DFT. (http://en.wikipedia.org/wiki/Kohn–Sham_equations)

http://www.tcm.phy.cam.ac.uk/~pdh1001/thesis/node17.html

@Red, do you use empirical methods to determine the position of the nucleons, and then your approximation to work out the electron distribution, or do you use the approximations to determine the positions and compare them to the empirical solution to ensure your approximations are good enough?

@orathaic, because a part of my research is confidential, i'll answer that question (and following questions) in a more generic fashion, if it's okay.
Actually there are several approaches toward having a geometry. Like I said, the BOA allows us to describe our chemical system by: method+atomic coordinates. That's obviously an excellent simplification of the time dependent Schrödinger equation when we're allowed to use it, as we almost always are. One exception is when using very heavy nuclei. The electrons in orbitals close to these nuclei have such high velocities, that their mass increases in accordance with Special Relativity. The mass of the electron is now no longer negligibly small compared to nucleon mass and you enter the extremely complicated realm of relativistic quantum chemistry.

How to obtain a geometry? Your first method is actually very often used, particularly for larger systems. X-ray diffraction can be used to determine the atomic positions of a molecule/crystal and this information is supplied to the Quantum Chemistry software that gives you an electronic density with the given structure.

You can instruct the computer to perform a second step, called an optimization. During an optimization, the forces working between the atoms are determined at a quantum chemical level (alternatively, you can use a "force field method", that uses empirical harmonic/morse potentials to put your atoms in the right positions; obviously, this is a much cruder procedure). You instruct your software to keep moving the atoms bit by bit in the direction the forces pull them (these forces being recalculated at every small change in atomic positions). Once certain thresholds are reached (the default thresholds are extremely tight, meaning you are 100% sure you actually reached a point where the atoms are at their energetically most favorable positions) the optimization is finished.

At this point, yes, you check back with experimental reality but not necessarily by comparing geometries (the experimental geometries may not be at your disposition), but you can correlate NMR resonance frequencies, all sorts of energy considerations, IR absorption frequencies, UV crossover points, interactions with enzymes etc. etc..

A much more interesting kind of optimization is a "transition state optimization". Whereas for a normal optimization you seek a general stationary point, a transition state is a point where a chemical step is taken (for example, the formation of a Hydrogen-Oxygen bond when hydrochloric acid is added to water; there is one specific point between the transfer of hydrogen from the chlorine to the oxygen where the energy is at its highest, this is a transition state).

Mathematically, a transition state is very rigorously defined. The atoms span up a multi-dimensional space (3N-6 dimensions for our particular purpose, in case of N>2 if I remember correctly) and an energy is associated to each point in this space. When looking for a transition state, one looks for the point where a change along any coordinate of this space increases the potential energy (so a minimum in all respects, as for a regular optimization) except for one particular coordinate, for which the energy goes down (you're at a maximum in energy like I explained, and formation of the product or return to the reactant lowers the energy). Mathematically, a point like this is known as a "saddle point" (http://en.wikipedia.org/wiki/Saddle_point)

Kinetics - besides establishing important data needed in the chemical manufacturing industry - is also useful for modeling reaction dynamics. Scientists start off knowing that if you dump a bunch of protein and a bit of an aromatic compound and a dash of catalyst into a flask, that you get something new. But exactly how you get from point A to B is usually not intuitive. When you add varying amounts of the different reagents, and then time the reaction progress, you can figure out how the different little critters are interacting with each other. Rate mechanisms, etc.

One of the nice things about kinetics is that one doesn't really need to include quantum calculations most of the time. In fact, one can say to a certain degree that quantum mechanics has implications in quantum mechanics more so than kinetics needing quantum mechanics.

Thanks Red, i'm familiar with the general numerical technique of " keep moving the atoms bit by bit in the direction the forces pull them" from my work on foam structure (but obviously using classical forces instead of quantum or even relativistic quantum for your heavier elements)

The steady state is all I have actually studied, so the method for finding the lowest energy transition state is very interesting, i was looking at different foam structures and the energy and stability of the state, so i could show where the structure became unstable but not what the transition would be, or how much energy was needed...

Obviously the rotational/vibrational modes of a chemical bond add to the complexity and make for a much harder system to solve (as Al said, without necessarily needing Quantum mechanics) But even in the simpler model of foam i'm not familiar with a simple/general method for modeling transitions where the energy is not a minimum (my models blew up with they went past a unstable location, which i guess is a problem with using someone else's software... )

OK, I'm lost... Anyone up for running a groundwater modeling simulation or using the Gaussian theory to calculate the worst case wind event based on the last century's data at a major international airport?

@Al, I'm not entirely following your last paragraph, but allow me to post an interesting link to some basic kinetics for the system you describe, so people can get a feel for that:
http://en.wikipedia.org/wiki/Michaelis–Menten_kinetics

@orathaic, as foam is typically constituted of clusters of complex macromolecules that have gas or liquids trapped inside them, I can assure you that you were at the maximum of scientific capacity with your project, as a foam system is several orders of magnitude larger than the typical system on which we perform QC calculations.

@Draug,
That sounds interesting, but what do you mean by the second one? Gaussian theory, or the Gaussian distribution? That last thing should be easy.

Gaussian distribution. When I coded it in 1991, the engineers needing me to write the C program called it Gaussian theory.

You should Excel the shit out of that.

The idea was to process 100 years of data from CVG airport (newer stuff was every few seconds, older was every few minutes going back to just a few times an hour) to compute the worst case wind event for the next hundred years so they could design material containment silos at Fernald to withstand everything shy of a direct tornado strike without overbuilding and costing the taxpayers unnecessary money.

@Red - It was 1990 before multicore processors on every tablet. It was written for amd run on an Iris Indigo.

Your model is flawed. Global warming makes winds extremer and your model doesn't seem to factor in possible changes in average wind strength in time. People will lose their lives over this error. Go home, think about your sins and ask the almighty for forgiveness.

Well that was almost 25 years ago amd I know they added 25% to the end number as a safety factor for unforeseen changes to the environment (1990 wasn't exactly a *global warming the sky is falling* time).

They also used my program to find temperature for ground contraction and expansion to prevent a critical failure of the grpund containment system.

Draugnar - dude, I have new respect for you. You are a real programmer.

Thread t = new Thread();
t.hijack();
return true;

adosseg
.model small
.stack 100h

.data
hello_message db 'Real Programmers write in FORTRAN.

Maybe they do now,
in this decadent era of
Lite beer, hand calculators, and "user-friendly" software
but back in the Good Old Days,
when the term "software" sounded funny
and Real Computers were made out of drums and vacuum tubes,
Real Programmers wrote in machine code.
Not FORTRAN. Not RATFOR. Not, even, assembly language.
Machine Code.
Raw, unadorned, inscrutable hexadecimal numbers.
Directly.

Lest a whole new generation of programmers
grow up in ignorance of this glorious past,
I feel duty-bound to describe,
as best I can through the generation gap,
how a Real Programmer wrote code.
I'll call him Mel,
because that was his name.

I first met Mel when I went to work for Royal McBee Computer Corp.,
a now-defunct subsidiary of the typewriter company.
The firm manufactured the LGP-30,
a small, cheap (by the standards of the day)
drum-memory computer,
and had just started to manufacture
the RPC-4000, a much-improved,
bigger, better, faster --- drum-memory computer.
Cores cost too much,
and weren't here to stay, anyway.
(That's why you haven't heard of the company,
or the computer.)

I had been hired to write a FORTRAN compiler
for this new marvel and Mel was my guide to its wonders.
Mel didn't approve of compilers.

"If a program can't rewrite its own code",
he asked, "what good is it?"

Mel had written,
in hexadecimal,
the most popular computer program the company owned.
It ran on the LGP-30
and played blackjack with potential customers
at computer shows.
Its effect was always dramatic.
The LGP-30 booth was packed at every show,
and the IBM salesmen stood around
talking to each other.
Whether or not this actually sold computers
was a question we never discussed.

Mel's job was to re-write
the blackjack program for the RPC-4000.
(Port? What does that mean?)
The new computer had a one-plus-one
addressing scheme,
in which each machine instruction,
in addition to the operation code
and the address of the needed operand,
had a second address that indicated where, on the revolving drum,
the next instruction was located.

In modern parlance,
every single instruction was followed by a GO TO!
Put *that* in Pascal's pipe and smoke it.

Mel loved the RPC-4000
because he could optimize his code:
that is, locate instructions on the drum
so that just as one finished its job,
the next would be just arriving at the "read head"
and available for immediate execution.
There was a program to do that job,
an "optimizing assembler",
but Mel refused to use it.

"You never know where it's going to put things",
he explained, "so you'd have to use separate constants".

It was a long time before I understood that remark.
Since Mel knew the numerical value
of every operation code,
and assigned his own drum addresses,
every instruction he wrote could also be considered
a numerical constant.
He could pick up an earlier "add" instruction, say,
and multiply by it,
if it had the right numeric value.
His code was not easy for someone else to modify.

I compared Mel's hand-optimized programs
with the same code massaged by the optimizing assembler program,
and Mel's always ran faster.
That was because the "top-down" method of program design
hadn't been invented yet,
and Mel wouldn't have used it anyway.
He wrote the innermost parts of his program loops first,
so they would get first choice
of the optimum address locations on the drum.
The optimizing assembler wasn't smart enough to do it that way.

Mel never wrote time-delay loops, either,
even when the balky Flexowriter
required a delay between output characters to work right.
He just located instructions on the drum
so each successive one was just *past* the read head
when it was needed;
the drum had to execute another complete revolution
to find the next instruction.
He coined an unforgettable term for this procedure.
Although "optimum" is an absolute term,
like "unique", it became common verbal practice
to make it relative:
"not quite optimum" or "less optimum"
or "not very optimum".
Mel called the maximum time-delay locations
the "most pessimum".

After he finished the blackjack program
and got it to run
("Even the initializer is optimized",
he said proudly),
he got a Change Request from the sales department.
The program used an elegant (optimized)
random number generator
to shuffle the "cards" and deal from the "deck",
and some of the salesmen felt it was too fair,
since sometimes the customers lost.
They wanted Mel to modify the program
so, at the setting of a sense switch on the console,
they could change the odds and let the customer win.

Mel balked.
He felt this was patently dishonest,
which it was,
and that it impinged on his personal integrity as a programmer,
which it did,
so he refused to do it.
The Head Salesman talked to Mel,
as did the Big Boss and, at the boss's urging,
a few Fellow Programmers.
Mel finally gave in and wrote the code,
but he got the test backwards,
and, when the sense switch was turned on,
the program would cheat, winning every time.
Mel was delighted with this,
claiming his subconscious was uncontrollably ethical,
and adamantly refused to fix it.

After Mel had left the company for greener pa$ture$,
the Big Boss asked me to look at the code
and see if I could find the test and reverse it.
Somewhat reluctantly, I agreed to look.
Tracking Mel's code was a real adventure.

I have often felt that programming is an art form,
whose real value can only be appreciated
by another versed in the same arcane art;
there are lovely gems and brilliant coups
hidden from human view and admiration, sometimes forever,
by the very nature of the process.
You can learn a lot about an individual
just by reading through his code,
even in hexadecimal.
Mel was, I think, an unsung genius.

Perhaps my greatest shock came
when I found an innocent loop that had no test in it.
No test. *None*.
Common sense said it had to be a closed loop,
where the program would circle, forever, endlessly.
Program control passed right through it, however,
and safely out the other side.
It took me two weeks to figure it out.

The RPC-4000 computer had a really modern facility
called an index register.
It allowed the programmer to write a program loop
that used an indexed instruction inside;
each time through,
the number in the index register
was added to the address of that instruction,
so it would refer
to the next datum in a series.
He had only to increment the index register
each time through.
Mel never used it.

Instead, he would pull the instruction into a machine register,
add one to its address,
and store it back.
He would then execute the modified instruction
right from the register.
The loop was written so this additional execution time
was taken into account ---
just as this instruction finished,
the next one was right under the drum's read head,
ready to go.
But the loop had no test in it.

The vital clue came when I noticed
the index register bit,
the bit that lay between the address
and the operation code in the instruction word,
was turned on ---
yet Mel never used the index register,
leaving it zero all the time.
When the light went on it nearly blinded me.

He had located the data he was working on
near the top of memory ---
the largest locations the instructions could address ---
so, after the last datum was handled,
incrementing the instruction address
would make it overflow.
The carry would add one to the
operation code, changing it to the next one in the instruction set:
a jump instruction.
Sure enough, the next program instruction was
in address location zero,
and the program went happily on its way.

I haven't kept in touch with Mel,
so I don't know if he ever gave in to the flood of
change that has washed over programming techniques
since those long-gone days.
I like to think he didn't.
In any event,
I was impressed enough that I quit looking for the
offending test,
telling the Big Boss I couldn't find it.
He didn't seem surprised.

When I left the company,
the blackjack program would still cheat
if you turned on the right sense switch,
and I think that's how it should be.
I didn't feel comfortable
hacking up the code of a Real Programmer.',0dh,0ah,'$'

.code
main proc
mov ax,@data
mov ds,ax

mov ah,9
mov dx,offset hello_message
int 21h

mov ax,4C00h
int 21h
main endp
end main

@redhouse: yes, but the assumptions being made were that the surfaces involved we not even made up of molecules - the marco-simulation was, i am sure, nowhere near as detailed as yours, because we weren't attempting to simulate the molecules involved.

That would be hard. or maybe i should say, very computationally intensive... but the same issues occur when it comes to simulating dynamic vs static energy minimums.
ie it becomes harder.