-Ran the other detection methods on the dataset:
vtpdetect found many spurious sources and was defining large areas as sources, which could be expected as it is geared for very faint and extended sources
-wavdetect- takes much longer and creates larger files, so it's easier to crop field and choose a chip to centralize the cluster core, which- counts found are much lower than the same source's counterpart using the other detection methods; also not ideal because it requires the input of parameters like wavelet length and false source detection rates, the best values for which I am not sure of.... also geared towards closely spaced and extended sources, which ours aren't for the most part.

Went back to try to make celldetect work, and I realized that the sources that I believed to be spurious were in fact valid, for the most part. Viewing in Ds9 was cropping the field and centralizing on one ccd chip, creating white space at the edges though the field continued.
Readjusting binning and resolution parameters allows for the entire array to be viewed.

This is good news for me because it seems to be the best suited detection method. However, using the other methods, I've noticed a pretty severe discrepancy in net counts for corresponding sources, which worries me about the validity of the counts. Also the count rate, NET_RATE, and exposure time, EXP_TIME data model outputs are not yet implemented in the celldetect version and are just arrays of zeros.
To find count rate, I went back and manually (using dmextract) extracted the net counts and exposure times to find the count rate. As the net counts found with dmextract and celldetect were different enough, I think this may be a pretty inaccurate way to do this. (for the possible matching source, net counts found manually were 62.5, whereas with celldetect 48.5). The exposure time with this method was 5102.559, and thus the count rate was 1.23*10^-2.

Because of this, finding the minimum count rate that we could expect to detect (to know if perhaps the source is present, with a flux too low to be detected) is proving variable based on detection method. For celldetect with a 3 sigma, the default seemingly the best value, the lowest rate is around 5.037e-3. Our two sources should theoretically be detectable, as their count rates are: 0931+3622 (1.5-2.5 *10^-2) and 1532+4727 (.9-1.9*10^-2). I computed this value using the full energy range (.5-8KeV) I am working on the minimum count rate for a much softer range (.1-1 Kev)
(should I be looking as low as .06-.1 KeV?- was the energy range given in "The Coolest X-Ray Emitting WD's" This seems very soft...?)
For our two sources, it still looks as though only 153225.49+472700.9 could match a source anywhere near it's supposed position- I haven't yet computed it's theoretical xray count rate.. will do that in the morning.....

Whoops...... by ***** I mean ~1.1Kev . It is found by extracting a spectrum in energy space of the region around the source and finding the peak energy from a histogram of count rate as a function of energy using dmextract... Not sure how valid this is because the short exposure and low counts of our data may not contain much useful spectrum info...

(Tying to) build an exposure map (converting the counts image into an image in flux units for chips 2,3,5,6,7,8 of j0931+3622, in our case, which supposedly helps account for dither motion, especially near the edge of the detector) in several steps- using "asphist" function and the asol1.fits file to compute aspect histograms and map aspect information during the event; then using "mkinstmap" and the msk1.fits and pkb0.fits files to make an instrument map during the event (for simplicity assuming a monoenergetic distribution of source photons at an energy level or ***** found from using dmextract to make a histogram of count-rate as a function of energy, not sure if this is an ok assumption...), then with mkexpmap and aspect info, projecting the instrument map onto the sky....

first had to learn basic for loops in the bash shell. The basic syntax is:

for var in list

do;

commands;

done

In the process of doing this I have found the Calibration Database is not properly accessible, so I am currently (and slowly, stupid internet) attempting to download and reinstall it to continue..
Not sure if having an exposure map will even help because I'm not sure if dithering edge effects are what are causing spurious detection, but thought I would try to go through the process...

Found position and fluxes for J093_3622 and J1532+4727:

8916: J093+3622

RA DEC NET_COUNTS

142.8321 36.3673    26.3125

142.8057 36.3789   25.750

8917: J1532+4727

RA DEC NET_COUNTS

233.1843 47.4015   48.557

we can now compare to optical data of these events.

Looking into issue of off-field spurious events- think it may be due to the recursive blocking nature of celldetect but I'm not sure. Trying to fix the cell parameter to see if that helps. So far little luck- the parameter must be 1 or a multiple of 3: 1 doesn't find both events (and counts the same event twice, offset by one pixel), 3 still comes up with 6 spurious events, 9 makes 11 spurious events, etc. Attempting to fix a cell and then vary the S/N threshold not particularly successful either. So probably not an effective solution. Trying to build an exposure map as it is supposed to help with edge effects...

Compiled table for the isolated neutron star data, comparing results in the standard, soft, and hard x-ray regimes from visually identifying events and getting counts with dmextract, and using celldetect. Events are mostly much stronger in the softer xrays, and only are detected once (6701) in the hard xray. 

 Generally celldetect corresponded well with visual results, and the counts extracted with dmextract, with a few deviations: in the standard and soft xray regimes of 6696, 6701, 6703, 6705 (I'm not sure offhand which event these folders correspond to, I will check) there appeared events (with relatively lower counts) that weren't detected with the thread. 

Playing around with some of the parameters of celldetect, namely in for this case the signal to noise threshold from the default value of 3 to 2, has more success- however I'm concerned that this would introduce more invalid source detection from the hot pixel cosmic ray issues;

will look more into those issues, and how present these errors may be- superficial reading of the help manual makes me think that the standard data processing that has already been applied would be sufficient.. 

Also found that celldetect in a few instances returned "events" whose positions were off the data's field. Confirmed that celldetect returns these same positions a second time. Not sure what that is about..

created corrected energy level files for the chandra data, played around with those. Estimated fluxes and positions with dmextract, played with region types, tried running celldetect and compared results. 

Continuing to attempt proper installation of Ciao. Reinstalled one million times- installs fine without the "tools" binary, which includes all the necessary data modeling tools- when installing with the "tools" binary, testing ciao returns the error "cannot execute binary." Confused.