POV-Ray : Newsgroups : povray.binaries.scene-files : Quantum Waves in Media Server Time
6 May 2024 11:29:48 EDT (-0400)
  Quantum Waves in Media (Message 6 to 15 of 15)  
<<< Previous 5 Messages Goto Initial 10 Messages
From: Tor Olav Kristensen
Subject: Re: Quantum Waves in Media
Date: 12 Jan 2003 19:39:57
Message: <Xns93021174078F7torolavk@204.213.191.226>
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

From: Jellby
Subject: Re: Quantum Waves in Media
Date: 13 Jan 2003 09:31:16
Message: <3e22cdb3@news.povray.org>
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

From: Jaap Frank
Subject: Re: Quantum Waves in Media
Date: 13 Jan 2003 15:46:40
Message: <3e2325b0$1@news.povray.org>
"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

From: Jaap Frank
Subject: Re: Quantum Waves in Media
Date: 13 Jan 2003 16:38:12
Message: <3e2331c4$1@news.povray.org>
"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

From: Tor Olav Kristensen
Subject: Re: Quantum Waves in Media - 1 attachment
Date: 13 Jan 2003 18:13:30
Message: <Xns93032CBAD891torolavk@204.213.191.226>
"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)

From: Jaap Frank
Subject: Re: Quantum Waves in Media - 1 attachment
Date: 14 Jan 2003 20:25:17
Message: <3e24b87d@news.povray.org>
"Tor Olav Kristensen" <tor### [at] hotmailcom> wrote in message
news:Xns### [at] 204213191226...

> > 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.

My knowledge isn't so big. At the university I've
had some basic quantum mechanics that I didn't
understand very good I must admit. Later my
understanding has grown because your insight
becomes better when you combine your knowledge.
(Mmmh .. I hope I make myself clear with this.)

> But apart from that; Yes I would like
> to have a look at the original functions.
> Just because I'm curious !

You find it in H_Wave_Text.pov, together with
an explanation about the imaginary part and
my translation principle of the derivative.

You will see that one factor in exp_imPhi has to be
put back:  'm / abs(m)'
If you omit that, then the function is equal for positive
and negative values of 'm'.
'm / abs(m)' gives just the difference you need.
If you render 2p1 and 2p-1 without that factor,
you get identical pictures and with the factor they
have different directions in space.

> 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.

Modest! It decreases render time with 25% with
my PIII 450MHz. That's considerable. Thank you
for that optimilization.
Your macro's and functions are very keen.
I couldn't have done that and so quickly.
I've still a lot to learn.

Now I have to find a formula for the container
radius, for, thanks to you, I can now choose
any combination I like!

Regards,

Jaap Frank


Post a reply to this message


Attachments:
Download 'H_Wave_Text.pov.txt' (3 KB) Download 'H_Wave_Functions v4_TOR.pov.txt' (26 KB)

From: Tor Olav Kristensen
Subject: Re: Quantum Waves in Media - 1 attachment
Date: 15 Jan 2003 18:58:47
Message: <Xns9305A7CFC16Dtorolavk@204.213.191.226>
"Jaap Frank" <jjf### [at] xs4allnl> wrote in news:3e24b87d@news.povray.org:
> 
> "Tor Olav Kristensen" <tor### [at] hotmailcom> wrote in message
> news:Xns### [at] 204213191226...
...
>> But apart from that; Yes I would like
>> to have a look at the original functions.
>> Just because I'm curious !
> 
> You find it in H_Wave_Text.pov, together with
> an explanation about the imaginary part and
> my translation principle of the derivative.

Thanks. I'll have a look at it to see if I
can "understand" it.


> You will see that one factor in exp_imPhi has to be
> put back:  'm / abs(m)'
> If you omit that, then the function is equal for positive
> and negative values of 'm'.
> 'm / abs(m)' gives just the difference you need.
> If you render 2p1 and 2p-1 without that factor,
> you get identical pictures and with the factor they
> have different directions in space.

Ok, I see. I must have misinterpreted your
function expression. This means that that
macro isn't really needed then.

This statement should give the same result:

#declare Exp_imPhi =
  function { cos(m*atan2(y, z)) + sin(m*atan2(y, z)) }


Since:

cos(AnyAngle) = cos(-AnyAngle)
sin(-m*AnyAngle) = -sin(m*AnyAngle)
cos(0*AnyAngle) + sin(0*AnyAngle) = 1

(Note that you should be careful with the use
of lowercase single character variable names
in your code. Because they are reserved for
future use in POV-Ray. I.e. they may get
special meanings in later POV-Ray versions.)

Even if the macro doesn't seem to be needed,
you could check if this version of it gives
any speed increase:


#macro Exp_imPhiFunction(M)

  #local imPhiFn =
    function(Angle) { cos(Angle) + sin(Angle) }

  function { imPhiFn(M*atan2(y, z)) }

#end // macro Exp_imPhiFunction


But I doubt that the speed difference will be
noticable.

(And in some cases, I think such an expression
will render slower. It remains for me to find
out in which cases it evaluates slower.)


One further little note:

If you want to use the sign of a variable in
an expression, then this:

select(variable, -1, 1, 1)

or:

select(variable, -1, 0, 1)

- would be a good way to write it.


As you have noticed; variable/abs(variable)
requires extra care to make sure that a
division by 0 does not happen when the
variable is equal to zero. And I believe that
such an expression also forces povray to do a
float division, instead of just a quick check
of some of the bits in the variable's value.


> Now I have to find a formula for the container
> radius, for, thanks to you, I can now choose
> any combination I like!
> 
> Regards,
> 
> Jaap Frank

I hope that you post the radius formula when
you find it Jaap.


Tor Olav


Post a reply to this message

From: Jaap Frank
Subject: Re: Quantum Waves in Media - 1 attachment
Date: 17 Jan 2003 13:06:11
Message: <3e284613@news.povray.org>
"Tor Olav Kristensen"  wrote

> This statement should give the same result:
>
> #declare Exp_imPhi =
>   function { cos(m*atan2(y, z)) + sin(m*atan2(y, z)) }
>
> Since:
> cos(AnyAngle) = cos(-AnyAngle)
> sin(-m*AnyAngle) = -sin(m*AnyAngle)
> cos(0*AnyAngle) + sin(0*AnyAngle) = 1

Yes, of course, that's the shortest way.

> Even if the macro doesn't seem to be needed,
> you could check if this version of it gives
> any speed increase:
>
> #macro Exp_imPhiFunction(M)
>
>   #local imPhiFn =
>     function(Angle) { cos(Angle) + sin(Angle) }
>
>   function { imPhiFn(M*atan2(y, z)) }
>
> #end // macro Exp_imPhiFunction
>
> But I doubt that the speed difference will be
> noticable.

I think that in this case there will be a slight profit,
because the atan2() is a serie expansion and that
takes considerable time.

> (And in some cases, I think such an expression
> will render slower. It remains for me to find
> out in which cases it evaluates slower.)

Only testing can give you the time needed to build
the subroutine that calls this 'sub-function'. That's
the loss you get if you nest deeper. So for time
consuming operations you can get a profit.

> One further little note:
> If you want to use the sign of a variable in
> an expression, then this:
>    select(variable, -1, 1, 1)
>    or:
>    select(variable, -1, 0, 1)
> - would be a good way to write it.
>
> As you have noticed; variable/abs(variable)
> requires extra care to make sure that a
> division by 0 does not happen when the
> variable is equal to zero. And I believe that
> such an expression also forces povray to do a
> float division, instead of just a quick check
> of some of the bits in the variable's value.

You can notice that I don't use these functions very
often, because I hadn't thought about this while I
used this function several times.

> I hope that you post the radius formula when
> you find it Jaap.

I think that the old fashioned formula for the Bohr
Radius might be a good choice to start with.
I have to test it jet.
When I made a preliminarily test with high values
of 'n', I discovered that I will have to invent a variable
intensity either, because the media got to dim.
If I have tested these things, I will let you know what
the solution for this will be (if I can find it).

Thanks again for all this tremendous help.


Jaap Frank


Post a reply to this message

From: Jaap Frank
Subject: Re: Quantum Waves in Media - 3 attachment
Date: 26 Jan 2003 16:49:33
Message: <3e3457ed@news.povray.org>
> > I hope that you post the radius formula when
> > you find it Jaap.
>
> I think that the old fashioned formula for the Bohr
> Radius might be a good choice to start with.
> I have to test it jet.
[..]
> If I have tested these things, I will let you know what
> the solution for this will be (if I can find it).
>

It took me a while to find a formula for the container radius, but I've found
something useful.
The following you can find in the attached file too.
(As you suggested I've changed the variables to upper case.)

/*  Container formula:
  The Bohr radii are proportional with N*N.
  For N=1 the quantum maximum equals the Bohr radius when R = 1,
  but for N=2 it's around 5*R instead of the expected 4*R.

  For the quantum functions I've found some interesting correction factors when
L = 0:
  - With N > 2 else it's nonsense.
  - The main maxima are around:    N*N * (N-1)/(N/2)
  - The fall off towards nearly zero: N*N * (N-1)/(N/2) * (N-1)/(N-2)
  - Expansion for very low values:  N*N * (N-1)/(N/2) * (N-1)/(N-2) * (1 +
0.4/N)
  It doesn't give the exact maxima, but it's amazingly close. The limit (N >>>)
is 2*N*N.

  L > 0:
  The deviation between the quantum maxima and the Bohr radii becomes smaller
for
  larger values of L.
  The maximum of the 2p is nearly 4*R, of the 3d it's nearly 9*R and of the 4f
nearly
  16*R.  The maxima of the 4p and 4d are between the 4s and the 4f.
*/

As you can see there is a regularity in the maxima. I was led by the fact that
these kind of factors are used in the wave function too, but it was trial and
error at first. The last factor contains 0.4 and is only a choice to keep the low
density part visible.
It can become smaller with increasing N, because the whole density is lower
then (total volume is 1 because of the normalization factor).

Further there are some small optimisations with pow() when the power is zero
or one. The speed increase was noticeable but not great. Well, all small steps
help.

I removed a bug from the macro CreateAxis() and made it ready for high
values of N.

Curiosity made me try some very high values of N, up to 100. With N=100
there's nothing to see. I went down and with N=77 it appears suddenly again,
although with very bad quality.
First I was puzzled about this, but 77 was somehow a familiar number. Then I
remembered that that is the maximum number for facultity in a normal calculator.
There are lots of facultities in the formula, so this must be the cause of this.

This brings me to another subject.
About a year ago I was trying to understand the working of  poly.cpp of the
source code of POV-Ray (3.1g). What I was (and still am) is figuring out
how a polynomial of high degree is solved for its roots.
I cannot code in C, but I've coded in Pascal (TurboPascal), so I can follow
(with some difficulty) what is done there.
In PolySolve the binomial(int n, int r) is heavily used, so I tried to figure
out
how that was done. In the loop there is a 'Goto' to get out of the loop when
something is found and done. That was the point where I couldn't follow it
anymore. To my opinion this was not done correctly, so a bug.
To proof myself, I coded this function in SDL and compared the results
with the strait forward method that I use in the wave functions too.
(Attachment Test_PolyC). It proofs that I was right about it. It's a bug.
Years ago I had poly.cpp printed from POV version 2_?  for another
reason and to my surprise the bug was already there. I think it may exist
from the beginning of POV-Ray!
In that time I hadn't internet (I was very late with that) and got POV_Ray
from a friend, so I couldn't report it. Because for the first 15 powers
there is a look up table it is possible that this bug doesn't show up, for
MaxPower = 15. Further I thought that this must be known and nobody
bothered about it.
To my surprise the bug still exists in version 3.5. It's possible that this
part is still unused, but maybe with the new possibilities with the functions
there is need for solving higher powers and then there is a problem with this
function.
I think it's no use that I report this, for I once found a strange behaviour
with brackets during the beta testing period, but got no reaction about this
after I had reported that.
Maybe they listen to you.

What do you think about this?

Regards,

Jaap Frank

PS Is your email tor### [at] hotmailcom still active?
      Bonus: A nice wave :).


Post a reply to this message


Attachments:
Download 'H_Wave_Functions v4_TOR_4.pov.txt' (29 KB) Download 'Test_PolyC.pov.txt' (14 KB) Download 'H_PROB_7H-3_MED_TOR_4.png' (363 KB)

Preview of image 'H_PROB_7H-3_MED_TOR_4.png'
H_PROB_7H-3_MED_TOR_4.png


 

From: Tor Olav Kristensen
Subject: Re: Quantum Waves in Media - 3 attachment
Date: 26 Jan 2003 17:22:59
Message: <Xns930FEE70ABAA1torolavk@204.213.191.226>
"Jaap Frank" <jjf### [at] xs4allnl> wrote in news:3e3457ed@news.povray.org:

>On 26 jan 2003, you wrote in povray.binaries.scene-files:
> 
>> > I hope that you post the radius formula when
>> > you find it Jaap.
>>
>> I think that the old fashioned formula for the Bohr
>> Radius might be a good choice to start with.
>> I have to test it jet.
> [..]
>> If I have tested these things, I will let you know what
>> the solution for this will be (if I can find it).
>>
> 
> It took me a while to find a formula for the container radius, but
> I've found something useful.
> The following you can find in the attached file too.
> (As you suggested I've changed the variables to upper case.)
...

That's good !


...
> PS Is your email tor### [at] hotmailcom still active?

Yes it is. - Sorry for not reading my email
so often these days.

I had just started reading your email to me,
when I saw your new post.

But I think I will need some time before I
am able to reply thoroughly. I will try to
look into the binomial() problem that you
describe.


>       Bonus: A nice wave :).

This 7h-3 image image is great too !


Tor Olav


Post a reply to this message

<<< Previous 5 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.