My function behaves as though (< (abs k) (* k 1e-5)) => t
which shouldn't be true for any value of k. I am very new to Lisp
(working on second program) and need help figuring this out.
The function below increments a global variable,
*iteration-count-mesh*, which keeps track of how many times the do loop
runs. I noticed that it only incremented once for each time I ran the
function. Also, the function's behavior does not change when I comment
out the the "when" line (and one of the parentheses after return... of
course). On the first time through the loop, k-old should be 0 (because
it isn't changed after (setf k-old k) where k is 0). *k-tolerance* is a
global variable with value 1e-5. Therefore, this loop should never stop
after one iteration, yet it always does.
I am posting only the relevant function, but the rest of the code can
be found at plaza.ufl.edu/lavigne/april7.lisp
My interpreter is Clisp (windows xp).
(defun criticality-refine
(flux-solver slab-length D v-sigma-f sigma-a albedoL albedoR)
(setf k 0)
(setf flux (make-array 3 :initial-element 1))
(do () (nil)
(incf *iteration-count-mesh*)
(setf dx (/ slab-length (1- (length flux))))
(setf k-old k)
(setf k
(criticality-fixed flux-solver flux
dx D v-sigma-f sigma-a albedoL albedoR))
(setf *flux* flux)
(when (< (abs (- k k-old)) (* k *k-tolerance*))
(return-from criticality-refine k))
(setf flux (expand-flux flux (/ dx 2) D sigma-a v-sigma-f))
)
)
Note:
This is a school assignment in nuclear engineering, but seeking help on
coding issues is encouraged. I am the only one in the class using Lisp.
Eric Lavigne wrote:
> My function behaves as though (< (abs k) (* k 1e-5)) => t
> which shouldn't be true for any value of k. I am very new to Lisp
> (working on second program) and need help figuring this out.
Picking one of many at random from the full source:
(defun criticality-fixed (flux-solver flux dx D
v-sigma-f sigma-a albedoL albedoR)
(setf k 1)
(setf flux-sum (loop for x across flux sum x))
...snip the rest...
...CLisp is probably treating k and flux-sum as specials, aka global.
Not sure how this could cause the when test to succeed, but I went thru
all your code and added local declarations to make all the "assumed
special" warnings go away (I am using AllegroCL), and now the test
function goes into an infinite loop. Perhaps that is the upshot you are
seeing? Anyway, a quick way to declare local variables would be:
(defun criticality-fixed (flux-solver flux dx D
v-sigma-f sigma-a albedoL albedoR
&aux k k-old flux-sum source)
(setf k 1)
(setf flux-sum (loop for x across flux sum x))
...etc...
You can also:
(let ((k 1)
(flux-sum (loop for x across flux summing x)))
....
If this does not help, make this the first statement in the when branch:
(print (list k k-old *k-tolerance*))
...and eyeball the output.
kenny
>
> The function below increments a global variable,
> *iteration-count-mesh*, which keeps track of how many times the do loop
> runs. I noticed that it only incremented once for each time I ran the
> function. Also, the function's behavior does not change when I comment
> out the the "when" line (and one of the parentheses after return... of
> course). On the first time through the loop, k-old should be 0 (because
> it isn't changed after (setf k-old k) where k is 0). *k-tolerance* is a
> global variable with value 1e-5. Therefore, this loop should never stop
> after one iteration, yet it always does.
>
> I am posting only the relevant function, but the rest of the code can
> be found at plaza.ufl.edu/lavigne/april7.lisp
> My interpreter is Clisp (windows xp).
>
> (defun criticality-refine
> (flux-solver slab-length D v-sigma-f sigma-a albedoL albedoR)
> (setf k 0)
> (setf flux (make-array 3 :initial-element 1))
> (do () (nil)
> (incf *iteration-count-mesh*)
> (setf dx (/ slab-length (1- (length flux))))
> (setf k-old k)
> (setf k
> (criticality-fixed flux-solver flux
> dx D v-sigma-f sigma-a albedoL albedoR))
> (setf *flux* flux)
> (when (< (abs (- k k-old)) (* k *k-tolerance*))
> (return-from criticality-refine k))
> (setf flux (expand-flux flux (/ dx 2) D sigma-a v-sigma-f))
> )
> )
>
> Note:
> This is a school assignment in nuclear engineering, but seeking help on
> coding issues is encouraged. I am the only one in the class using Lisp.
>
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
>My function behaves as though (< (abs k) (* k 1e-5)) => t
>which shouldn't be true for any value of k. I am very new to Lisp
>(working on second program) and need help figuring this out.
>On the first time through the loop, k-old should be 0 (because
>it isn't changed after (setf k-old k) where k is 0).
Several people have pointed out that, due to my sloppy variable
handling, there is no guarantee that k-old will be 0 as I expected it
to be. I am in the process of fixing this problem throughout my
program, not just in the place that it created an obvious bug. Thank
you for your help.
Eric
"Eric Lavigne" <············@gmail.com> writes:
> On the first time through the loop, k-old should be 0 (because
> it isn't changed after (setf k-old k) where k is 0).
Your CRITICALITY-FIXED function changes K-OLD.
To fix this, use LET or &AUX.
Eric Lavigne wrote:
> This is a school assignment in nuclear engineering, but seeking help
on
> coding issues is encouraged. I am the only one in the class using
Lisp.
Welcome! Looks like you're working on cool stuff in a cool language.
>>This is a school assignment in nuclear engineering...I am the only
one in the class using Lisp.
>Welcome! Looks like you're working on cool stuff in a cool language.
The follow-up is even cooler. Over the next 3 weeks, I will write a 3D
diffusion code with arbitrary geometry, material varying by region, and
two energy levels (current code is 1D, slab, homogenous, one energy
level). The hardest issue I am anticipating so far is speed
optimization. The current code has reasonable speed for what it is
doing (around 15 seconds to complete the job), but a 3D model will have
a lot more nodes. Multiplying 15 seconds by 1000... that's too long to
wait if I'm running it over and over again during development.
The 1D code (that you all helped me to fix) is completed and posted on
my website: plaza.ufl.edu/lavigne/
Thanks for all your help.
Eric