 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
the attached scene-files produce pictures of the
quantum wave functions of hydrogen.
I've put an example too.
There are two possibilities for viewing. Both are
the density of the media inside a sphere and the
density is color-represented.
Probability Distribution.
This is the chance to find an electron somewhere
around the nucleus. The density is equal to the chance.
Wave Function.
This is the mathematical description of the wave
and the density is equal to the amplitude of the wave.
Version 3_8 is made with hand-derived functions
and is limited to n = 4 (main quantum number).
Version 4_1 is extended to n = 10 and uses
computer generated derivatives. There is a slight
difference between the results, but I can't find the cause
of this. Somehow the waves are a little bit bigger with 4_1.
If you know something about quantum numbers, then
you can go ahead with them directly:
Change the settings (explanation provided) and run it.
Test the settings first with small pictures, for the media
are not so fast.
For those who this stuff is new:
I will keep this as simple as is possible.
In modern science the electron is described as a wave
that has an electrical charge and a mass.
As a result of this, the electron can't move freely around
the nucleus as a rocket around the earth, but has to
comply to certain mathematical rules.
Some (awful) mathematical manipulations result in a
very complicated function that is called the wave-function.
In this function you find three variables that are natural
numbers( 0, 1, 2, ...) and these are called the quantum
numbers:
('l' : this is the letter 'l' that follows the letter 'k'. With my font
this is almost equal to the number 1. I'll put them between
''.)
'n' = main quantum number ('n' = 1, 2, 3, ..)
This influences the radius of the wave. In short: how big.
'l' = second quantum number (officially the azimuthal
quantum number) ('l' = 0, 1, .., 'n'-1)
This influences the model of the wave and is equal
to the number of knots in the wave.
You can vary 'l' between 0 and 'n'-1.
'm' = third quantum number (officially the magnetic
quantum number) ('m' = -'l', .., 0, .., +'l')
This influences directions in space.Moving
electrical charges generate magnetic fields
and this number has something to do with that.
You can vary 'm' between -'l' and +'l'.
Let us give an example:
You choose 'n' = 3.
You now can vary 'l' : 0, 1 and 2 . Choose 'l' = 1.
You now can vary 'm': -1, 0, 1
Choose the combination 'n = 3, 'l' = 1 and 'm' = 0
and you get the quantum wave that is called 3p0.
There are more things that you can choose, but
I hope that the explanation is sufficient. You
can always ask!
Regards,
Jaap Frank
Post a reply to this message
Attachments:
Download 'H_Wave_Functions v3_8.pov.txt' (45 KB)
Download 'H_Wave_Functions v4_1.pov.txt' (31 KB)
Download 'H_PROB_6H0_MED.png' (184 KB)
Preview of image 'H_PROB_6H0_MED.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jaap Frank wrote:
> the attached scene-files produce pictures of the
> quantum wave functions of hydrogen.
>
> [...]
Thanks, I see it's too complicated for a quick look, but I'll study it when
I have a little more time. In case you're interested I attach my own
version of hydrogen-like orbitals, I use a macro to define the orbital
functions, and these functions can be used with media or isosurfaces.
It seemed to work faster if I defined the functions and the normalization
factors separately.
A simple example:
DefineOrbital(2,0,0,2,0.05) // 2s orbital for Z=2, threshold=0.05
#declare c1 = <-10,-10,0>;
#declare c2 = <10,10,10>;
isosurface {
function { Orb_pos(x,y,z) }
contained_by { box { c1,c2 } }
accuracy 0.001
evaluate 0.7, 1.0, 1.0
all_intersections
pigment { color rgb <0,1,0> }
finish { brilliance 2.0 phong 0.5 phong_size 100 }
}
isosurface {
function { Orb_neg(x,y,z) }
contained_by { box { c1,c2 } }
accuracy 0.001
evaluate 0.7, 1.0, 1.0
all_intersections
pigment { color rgb <1,0,0> }
finish { brilliance 2.0 phong 0.5 phong_size 100 }
}
P.S. I neglected the 4*pi factor in the probability density.
P.P.S. Can an isosurface be declared and then the function be altered?
--
Linux User #289967 (counter.li.org)
PGP Pub Key ID: 0x01A95F99 (pgp.escomplinux.org)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jellby wrote:
> In case you're interested I attach my own version of hydrogen-like
> orbitals
oops, I forgot that.
--
Ignacio Fernández Galván
Linux User #289967 (counter.li.org)
PGP Pub Key ID: 0x01A95F99 (pgp.escomplinux.org)
Post a reply to this message
Attachments:
Download 'us-ascii' (5 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jaap Frank" <jjf### [at] xs4all nl> wrote in message news:3e20f2e3@news.povray.org...
> Hello,
>
> Version 3_8 is made with hand-derived functions
> and is limited to n = 4 (main quantum number).
> Version 4_1 is extended to n = 10 and uses
> computer generated derivatives. There is a slight
> difference between the results, but I can't find the cause
> of this. Somehow the waves are a little bit bigger with 4_1.
Tor Olav have found it and shame on me:
>There seems to be some cut-n-paste errors
>in your Sigma_n_l() function. CS_5 and
>CS_6 are repeated several times in place
>of CS_7 -> CS_10.
He 's definitely right. Change the last CS_constants into
CS_7 -> CS_10. (starting in line 241)
Now the clouds are the expected dimension.
Starting in line 106 of the file you find:
#switch (n) // Switch container radius for electron cloud.
#case (1) #declare Radius = 7.1/Exp; #break
#case (2) #declare Radius = 17/Exp; #break
#case (3) #declare Radius = 30/Exp; #break
#case (4) #declare Radius = 50/Exp; #break
#case (5) #declare Radius = 70/Exp; #break
#case (6) #declare Radius = 90/Exp; #break
#case (7) #declare Radius = 115/Exp; #break
#case (8) #declare Radius = 140/Exp; #break
#case (9) #declare Radius = 165/Exp; #break
#case (10) #declare Radius = 190/Exp; #break
Change this part too from 7 to 10. The Radius
can now be much smaller.
Now the bug is gone, there's no need for Version 3_8
anymore. That's history now.
Tor Olav has suggested several speed optimizations and
is checking more possibilities. If that's all done, I will post
that, if anyone is interested.
Regards,
Jaap Frank
PS
> ('l' : this is the letter 'l' that follows the letter 'k'. With my font
> this is almost equal to the number 1. I'll put them between
> ''.)
I hope everybody has understand that 'letter' should be
'character'. 'Letter' is the dutch word for it and because
it's an normal english word, I've not noticed that I used it
wrong.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jellby" <jel### [at] M-yahoocom> wrote in message
news:3e217097@news.povray.org...
> Jaap Frank wrote:
>
> > the attached scene-files produce pictures of the
> > quantum wave functions of hydrogen.
> >
> > [...]
>
> Thanks, I see it's too complicated for a quick look, but I'll study it when
> I have a little more time. In case you're interested I attach my own
> version of hydrogen-like orbitals, I use a macro to define the orbital
> functions, and these functions can be used with media or isosurfaces.
I've had a quick look at your functions. I wiil study
them this week again, but the same thing applies for me:
time. I'm a teacher and tomorrow waits another school day.
> It seemed to work faster if I defined the functions and the normalization
> factors separately.
If you put them inside the functions, they are calculated everytime
the function is called, so because they are constants for a set of quantum
numbers, you better can declare them separately.
If you use my file you will be surpriced that the orientation of the orbitals
from my functions are different then from yours. That was a surprice
for me too, when I saw them the first time. I think that the following
has happened. Because atoms don't carry coordinate systems around,
the functions can be simplified by turning them along these axes.
I don't know if this is true, but I suspect this.
For the probability distribution you use:
#declare f_Den = function(x,y,z) { pow(f_Orb(x,y,z),2) }
I've found in the book where I found my wave-functions
that it's better to multiply f_Den with 4*pi*R^2 for this is the surface
of the sphere where you look for your probability.
( R = sqrt(x*x+y*y+z*z), so you have to put it inside the declaration
for the f_Den function)
I've seen pictures with and without this factor. It seems that it is not
a big deal, but the probability distributions are not totaly the same.
Then you do this:
......
#declare Norm = n_Ang*n_Rad;
#declare f_Orb = function(x,y,z) { f_Ang(x,y,z)*f_Rad(x,y,z) }
#declare f_Den = function(x,y,z) { pow(f_Orb(x,y,z),2) }
#declare Orb_pos = function(x,y,z) { value/Norm - f_Orb(x,y,z) }
#declare Orb_neg = function(x,y,z) { value/Norm + f_Orb(x,y,z) }
#declare Orb = function(x,y,z) { value/Norm - abs(f_Orb(x,y,z)) }
#declare Den = function(x,y,z) { value/(Norm*Norm) - f_Den(x,y,z) }
It seems to me that you divide everything by Norm, but then your
dimensions are not correct anymore. You now have f_Orb(x,y,z) / Norm.
And why do you subtract the orbital from value?
Norm is part of the wave function and you use it separately.
I can't follow this. Can you explain?
[..]
> P.S. I neglected the 4*pi factor in the probability density.
See above.
> P.P.S. Can an isosurface be declared and then the function be altered?
The function that you use inside the isosurface have to be declared before,
else you get an error. But maybe you mean something else?
Regards,
Jaap Frank
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jaap,
in the beginning of the v4_1 file you write this:
{ v }
k { v ( n+l ) 1 ( 2r ) }
Sigma { (-1) . ( ) . - . ( -- ) }
v=0 { ( k-v ) v! ( n ) }
But where you build this sigma function you
write something roughly like this:
#declare CS_v = Binom(n + l, k - v)/Fac(v)/pow(n, v);
And thereafter you add and subtract together
all these for v = 0 to k. Like this:
CS_v*pow(f_r(x, y, z), v)
But what happened to pow(2, v) ?
Is it taken care of somewhere else ?
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jaap Frank wrote:
> For the probability distribution you use:
>
> #declare f_Den = function(x,y,z) { pow(f_Orb(x,y,z),2) }
>
> I've found in the book where I found my wave-functions
> that it's better to multiply f_Den with 4*pi*R^2 for this is the surface
> of the sphere where you look for your probability.
> ( R = sqrt(x*x+y*y+z*z), so you have to put it inside the declaration
> for the f_Den function)
> I've seen pictures with and without this factor. It seems that it is not
> a big deal, but the probability distributions are not totaly the same.
Yes, I know, I didn't actually check it, just recalled the probability was
the function squared and didn't remember the 4*pi*r*r factor, it's a
mistake on my part :)
> Then you do this:
> ......
> #declare Norm = n_Ang*n_Rad;
> #declare f_Orb = function(x,y,z) { f_Ang(x,y,z)*f_Rad(x,y,z) }
> #declare f_Den = function(x,y,z) { pow(f_Orb(x,y,z),2) }
>
> #declare Orb_pos = function(x,y,z) { value/Norm - f_Orb(x,y,z) }
> #declare Orb_neg = function(x,y,z) { value/Norm + f_Orb(x,y,z) }
>
> #declare Orb = function(x,y,z) { value/Norm - abs(f_Orb(x,y,z)) }
> #declare Den = function(x,y,z) { value/(Norm*Norm) - f_Den(x,y,z) }
>
> It seems to me that you divide everything by Norm, but then your
> dimensions are not correct anymore. You now have f_Orb(x,y,z) / Norm.
> And why do you subtract the orbital from value?
> Norm is part of the wave function and you use it separately.
> I can't follow this. Can you explain?
I can explain, but I don't know if it has any sense. Since I was using the
functions for isosurfaces, I wanted to see the surface where Norm*f_Orb =
value, which is the same as f_Orb = value/Norm and the same as
value/Norm-f_Orb = 0 (in this way, so that the zones with higher values are
*inside* the isosurface. For the negative part, I wanted Norm*f_Orb =
-value. It seemed it rendered faster in this way.
>> P.P.S. Can an isosurface be declared and then the function be altered?
>
> The function that you use inside the isosurface have to be declared
> before, else you get an error. But maybe you mean something else?
I meant something like:
#declare foo = isosurface { blah, blah texture { cool_texture } }
isosurface {
foo
function { this(x,y,z) }
}
isosurface {
foo
function { that(x,y,z) }
}
I think I tried it and it didn't work
--
Linux User #289967 (counter.li.org)
PGP Pub Key ID: 0x01A95F99 (pgp.escomplinux.org)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jellby" <jel### [at] M-yahoocom> wrote in message
news:3e22cdb3@news.povray.org...
> I can explain, but I don't know if it has any sense. Since I was using the
> functions for isosurfaces, I wanted to see the surface where Norm*f_Orb =
> value, which is the same as f_Orb = value/Norm and the same as
> value/Norm-f_Orb = 0 (in this way, so that the zones with higher values are
> *inside* the isosurface. For the negative part, I wanted Norm*f_Orb =
> -value. It seemed it rendered faster in this way.
It certainly make sense. Now your isosurface is that part of the proba-
bility distribution that is equal to 'value'. I haven't thought about the
isosurfaces.
But if you use it for density in media, then you have to use the 'normal'
function. The advance of media is that you can see the inner structure too.
By the way, I've shifted the value of the wave function by 0.5, in order to
be in the middle of the range 0 .. 1 for the color_map if you visualize the
wave function itself. It's about the same tric.
> I meant something like:
>
> #declare foo = isosurface { blah, blah texture { cool_texture } }
>
> isosurface {
> foo
> function { this(x,y,z) }
> }
> isosurface {
> foo
> function { that(x,y,z) }
> }
>
> I think I tried it and it didn't work
>
I think it won't work because if you declare a isosurface the
function has to be inside it's '{}'. But you can better ask that
the real advanced guys. (p.a-u) :)
Jaap Frank
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tor Olav Kristensen" <tor### [at] hotmailcom> wrote in message
news:Xns### [at] 204213191226...
>
> Jaap,
> in the beginning of the v4_1 file you write this:
>
>
> { v }
> k { v ( n+l ) 1 ( 2r ) }
> Sigma { (-1) . ( ) . - . ( -- ) }
> v=0 { ( k-v ) v! ( n ) }
>
>
> But where you build this sigma function you
> write something roughly like this:
>
> #declare CS_v = Binom(n + l, k - v)/Fac(v)/pow(n, v);
>
> And thereafter you add and subtract together
> all these for v = 0 to k. Like this:
>
> CS_v*pow(f_r(x, y, z), v)
>
>
> But what happened to pow(2, v) ?
>
> Is it taken care of somewhere else ?
>
>
> Tor Olav
I'm afraid your totally right. It's missing.
I've put pow(2,v)* in front of the rest and rendered
the last file again. I suspected a difference but there's
not the slightest difference! This picture is with n = 10,
so all the constants are used.
I must have been very sloppy when I coded that part.
Normally I check everything twice, but something
must have caused that I never looked at it again.
I remember (it's nearly a year ago now) that I got
scrambled orbitals because sum() and prod() didn't
do what I expected and put al my attention in that.
But that's no excuse for such an error.
Thanks again!
BTW, are you interested in the original functions?
The first part of the radial part of the function I've
reorganised, because a couple of variables occur
several times and this is gives a faster code.
With respect for your thorough checking,
Jaap Frank
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jaap Frank" <jjf### [at] xs4allnl> wrote in news:3e2331c4$1@news.povray.org:
>
> "Tor Olav Kristensen" <tor### [at] hotmailcom> wrote in message
> news:Xns### [at] 204213191226...
...
>> But what happened to pow(2, v) ?
>>
>> Is it taken care of somewhere else ?
>>
>>
>> Tor Olav
>
> I'm afraid your totally right. It's missing.
> I've put pow(2,v)* in front of the rest and rendered
> the last file again. I suspected a difference but there's
> not the slightest difference! This picture is with n = 10,
> so all the constants are used.
OK. That's good.
> BTW, are you interested in the original functions?
> The first part of the radial part of the function I've
> reorganised, because a couple of variables occur
> several times and this is gives a faster code.
Jaap, I must admit that I know almost
nothing about quantum mechanics. So I
don't really understand the formulas
that I now have modified.
But apart from that; Yes I would like
to have a look at the original functions.
Just because I'm curious !
I have now had time to do some opti-
mizations to the math part of your
code, but I'm afraid the speed
increase are rather modest.
You can find the changes in the
attatched .pov-file.
Please feel free to ask if you wan't me
to comment on any of the changes.
Note that there are a few more small
changes that could be done to your code
to make it a little simpler.
> With respect for your thorough checking,
I'm happy that I could help you :)
Tor Olav
Post a reply to this message
Attachments:
Download 'H_Wave_Functions_v4_1_mod.pov.txt' (5 KB)
|
|
| |
| |
|
|
|
|
| |
|
|
