Would the 'cliffs and ledges' I saw on the mountain slopes be related to the 0.45 anomaly? If so (or even if not), would anyone like to suggest a way of re-analysing the data to focus on this new feature - or would anyone like a copy of the dataset to plug into their own graph?
Not sure this is the right thread, but maybe we should discuss the "theory" here and the "practical" RR stuff in the "How to .." thread in order not to bury the RR info under tons of math :-)
Anyway... Here are some preliminary results from my attempts to determine some cycle lengths from the actual results.
The assumption is that any result returning skypoints at (or very, very near) the "north pole" of the sky grid will mark a "phase 0" workunit, so the seq number must be a multiple of the period
The assumption is that any result returning skypoints at (or very, very near) the "north pole" of the sky grid will mark a "phase 0" workunit, so the seq number must be a multiple of the period
OK, sounds good. So (pardon my ignorance) how do you tell if a result is returning skypoints at the "north pole"?
The assumption is that any result returning skypoints at (or very, very near) the "north pole" of the sky grid will mark a "phase 0" workunit, so the seq number must be a multiple of the period
OK, sounds good. So (pardon my ignorance) how do you tell if a result is returning skypoints at the "north pole"?
Well, there's a cold wind blowing and you see elves running around your room... ;-)
The assumption is that any result returning skypoints at (or very, very near) the "north pole" of the sky grid will mark a "phase 0" workunit, so the seq number must be a multiple of the period
OK, sounds good. So (pardon my ignorance) how do you tell if a result is returning skypoints at the "north pole"?
Well, there's a cold wind blowing and you see elves running around your room... ;-)
Lol! Actually I guess I was wrong and it's the "south pole"... anyway....
You can tell by intercepting the result file that gets generated by the E@H app before it's deleted after the upload. I do this via a proxy in my LAN.
The file that is uploaded is a zipped ASCII file with 5 columns of numbers, two of the columns are for sky positions in RA/Dec coordinates. If Dec is close to -pi/2, I assume it's a "phase 0" workunit marking the beginning of a cycle. All WUs with sequence no 0 satisfy this condition.
CU
H-B
The file that is uploaded is a zipped ASCII file with 5 columns of numbers, two of the columns are for sky positions in RA/Dec coordinates. If Dec is close to -pi/2, I assume it's a "phase 0" workunit marking the beginning of a cycle. All WUs with sequence no 0 satisfy this condition.
OK, thanks. I've found where I can actually see RA/Dec while a task is crunching. You mention columns of numbers. You also mention that Dec needs to be -pi/2. Is that value constant throughout the column?
The file that is uploaded is a zipped ASCII file with 5 columns of numbers, two of the columns are for sky positions in RA/Dec coordinates. If Dec is close to -pi/2, I assume it's a "phase 0" workunit marking the beginning of a cycle. All WUs with sequence no 0 satisfy this condition.
OK, thanks. I've found where I can actually see RA/Dec while a task is crunching. You mention columns of numbers. You also mention that Dec needs to be -pi/2. Is that value constant throughout the column?
No, it's not constant. The workunits at the poles will have many skypoints over a wider range of declination, so the indication of a "phase 0" WU is that there EXISTS a value in the 3rd column that would be near -Pi/2 (say, < -1.55 should be ok for frequencies up to 900 Hz).
No, it's not constant. The workunits at the poles will have many skypoints over a wider range of declination, so the indication of a "phase 0" WU is that there EXISTS a value in the 3rd column that would be near -Pi/2 (say, < -1.55 should be ok for frequencies up to 900 Hz).
What directory does this file appear in while the result is in process? What is an example of the file name?
Most important, do you have a way to identify trough files by a similar method?
The reason I ask, is that the greater than 800 Hz work I'm getting at the moment is rather firmly between peaks, I have a much higher change of getting a trough file.
What directory does this file appear in while the result is in process? What is an example of the file name?
This data apeears in two places: in the slots/*/ sundirectory as a checkpoint file, but here the file is updated permanently and is stored in a binary format, not something that is easily processed.
When the result is finished, a zipped ASCII file of the described format is stored in the BOINC/projects/einstein.phys.uwm.edu/ subfolder. It will stay there until it is uploaded (if network mode is set to supspended, it will stay there until the next manual update). Filename will be like the workunit name:
h1_ffff.ff_S5R2__sss_S5R3a_i_j
Quote:
Most important, do you have a way to identify trough files by a similar method?
For trough WU files the declination will be close to zero, so (say) abs(dec) < 0.3
Quote:
The reason I ask, is that the greater than 800 Hz work I'm getting at the moment is rather firmly between peaks, I have a much higher change of getting a trough file.
Note that the declination is also displayed in the sceensaver view (given in degrees, not radians as in the result file). If the orange crosshair is near the "equator" and the Dec value close to 0, it's a trough WU.
I should still have the raw
)
I should still have the raw data for this chart:
(direct link)
which seems to have been where all this started!
Would the 'cliffs and ledges' I saw on the mountain slopes be related to the 0.45 anomaly? If so (or even if not), would anyone like to suggest a way of re-analysing the data to focus on this new feature - or would anyone like a copy of the dataset to plug into their own graph?
Hi! Not sure this is the
)
Hi!
Not sure this is the right thread, but maybe we should discuss the "theory" here and the "practical" RR stuff in the "How to .." thread in order not to bury the RR info under tons of math :-)
Anyway... Here are some preliminary results from my attempts to determine some cycle lengths from the actual results.
The assumption is that any result returning skypoints at (or very, very near) the "north pole" of the sky grid will mark a "phase 0" workunit, so the seq number must be a multiple of the period
So here are some of my findings:
frequency in WU name , period
160.55 , 6
181.05 , 8
255.60 , 14
641.20 , 86
662.80 , 92
699.15 , 100
699.25 , 100
775.55 , 124
751.95 , 118
Unfortunately, the frequencies are not close enough to be sure about the step-function theory...
There might be some more results tomorrow, I'm currently rebuilding the database (with > 13 Mio result rows, this takes some time :-) ).
CU
Bikeman
RE: The assumption is that
)
OK, sounds good. So (pardon my ignorance) how do you tell if a result is returning skypoints at the "north pole"?
Cheers,
Gary.
RE: RE: The assumption is
)
Well, there's a cold wind blowing and you see elves running around your room... ;-)
RE: RE: RE: The
)
Lol! Actually I guess I was wrong and it's the "south pole"... anyway....
You can tell by intercepting the result file that gets generated by the E@H app before it's deleted after the upload. I do this via a proxy in my LAN.
The file that is uploaded is a zipped ASCII file with 5 columns of numbers, two of the columns are for sky positions in RA/Dec coordinates. If Dec is close to -pi/2, I assume it's a "phase 0" workunit marking the beginning of a cycle. All WUs with sequence no 0 satisfy this condition.
CU
H-B
RE: The file that is
)
OK, thanks. I've found where I can actually see RA/Dec while a task is crunching. You mention columns of numbers. You also mention that Dec needs to be -pi/2. Is that value constant throughout the column?
Cheers,
Gary.
RE: RE: The file that is
)
No, it's not constant. The workunits at the poles will have many skypoints over a wider range of declination, so the indication of a "phase 0" WU is that there EXISTS a value in the 3rd column that would be near -Pi/2 (say, < -1.55 should be ok for frequencies up to 900 Hz).
CU
Bikeman
RE: No, it's not constant.
)
What directory does this file appear in while the result is in process? What is an example of the file name?
Most important, do you have a way to identify trough files by a similar method?
The reason I ask, is that the greater than 800 Hz work I'm getting at the moment is rather firmly between peaks, I have a much higher change of getting a trough file.
Thanks for any information
RE: What directory does
)
This data apeears in two places: in the slots/*/ sundirectory as a checkpoint file, but here the file is updated permanently and is stored in a binary format, not something that is easily processed.
When the result is finished, a zipped ASCII file of the described format is stored in the BOINC/projects/einstein.phys.uwm.edu/ subfolder. It will stay there until it is uploaded (if network mode is set to supspended, it will stay there until the next manual update). Filename will be like the workunit name:
h1_ffff.ff_S5R2__sss_S5R3a_i_j
For trough WU files the declination will be close to zero, so (say) abs(dec) < 0.3
Note that the declination is also displayed in the sceensaver view (given in degrees, not radians as in the result file). If the orange crosshair is near the "equator" and the Dec value close to 0, it's a trough WU.
CU
Bikeman
OK, here is the complete list
)
OK, here is the complete list of actually observed period lengths:
frequency in WU name , period
160.55 , 6
166.30 , 6
181.05 , 8
255.60 , 14
335.10 , 24
578.35 , 69
641.20 , 86
662.80 , 92
662.85 , 92
699.15 , 100
699.25 , 100
705.70 , 103
732.00 , 112
751.95 , 118
775.55 , 124
I think there's some evidence of a step function.
I suggest the following:
period = floor ( (ceil(freq/10)*10) ^ 2 * c + 0.5)
where c should be close to 0.0002044