This command given at the UNIX/Linux
command line prompt uses the nohup (no hangup) command to allow the
process to keep running even after I have terminated my connection with
the machine (in this case, helios). The nice command is simply
good manners, meaning that I'm willing to share the computer's
resources as needed until my process is finished. sswidl doesn't
work here; only idl. The arrows indicate I/O redirection, the
batchfile is what is being run, the ampersands indicate that this is
all done in the background (allowing me to work on other things in the
meantime if I wish to), and log is the file to which all output is
redirected. The corresponding syntax for doing this with a
general program.pro in IDL is:
nohup echo program | nice idl >& log &
June 22, 2009
I spent today working on BOTH of my major
projects. In FLUX world, I worked (and am still working on)
running relaxations and tracings which will allow me to compare
specific fluxons with specific results from the DA data cube.
This will let us see the actual differences between our results in
visual form, rather than simply via plots and charts of numbers.
I'd like to see if I can include color in some of these plots to help
make them a bit more visually appealing as well.
On the coronal tomography side of things, I've
added the background implementation code into the test program that's
run as a test-wrapper for Dr. Kankelborg's smart3d inversion
program. However, the actual background subtraction may not be
working as well as we'd hoped. If the background is not
successfully zeroed (completely, or very nearly so), then the smart3d
program appears to choke and be unable to converge on a solution.
I'm working on making the background selection and subtraction a bit
more effective, but I need to do a bit more brainstorming to ensure
that I fully understand the options which are available to me.
June 23, 2009
Having implemented the wrapper-test program
(test5.pro) to include the background, perform the subtraction and
perform the inversion algorithm with smart3d, it appears that if the
background is not adequately zeroed (or very nearly so), smart3d chokes
and is unable to converge to an acceptable solution (however, in some
cases, the chi-square statistics were rather poor, but the actual
reconstructed results looked quite nice). I'll be spending today
trying to tweak my implementation and help smart3d converge to a
solution.
Also, I'm reviewing a bit of FLUX/PDL
terminology and syntax so that I can ultimately generate some images
which show a fluxon aligned with its corresponding field line in the
DeVore/Antiochos results. More to follow on how this develops.
June 29, 2009
I worked on comparing the FLUX results line by
line with the DA results in different colors, which I finally did
successfully today! Hooray. Also, I spent a bit working
with Dr. Kankelborg on some alternative ways to model the background
for subtraction. However, I have yet to play with the smoothing
parameter in smart3d, which is the next step.
July 2, 2009
Varying the smoothness parameter did little to
affect the resulting convergence (or lack thereof) of smart3d to a
reduced chi-square statistic of unity, although the final reconstructed
volumes were impressively similar. I attempted to recalculate the
chi-square statistics by comparing the original projections to the sum
of the foreground and background model, but to little avail.
Planning to use my time today to work on developing some residual
measures of the source of divergent error (e.g., foreground or
background?), for the sake of analysis and possibly improvement.
Are we expecting too much from smart3d at this point? TIme will
tell.