OK, here is the complete list of actually observed period lengths:
For comparison, here are the periods implied for several specific frequencies, including the ones for which you've provided observations here, according to three models proposed over time:
I've padded with annoying leading zeros to avoid even more annoying column mismatch.
Bobs: observed valued reported in your post
Afun1: predicted values by my earliest quadratic estimate: .000206*freq^2
Afun2: predicted by most recent request to Mike: 0.00020417*(Ceiling(freq,10) + 0.433)^2
Bfune1: your most recent suggestion: floor(((Ceiling(freq,10)^2)*0.0002044+0.5),1)
Quote:
I suggest the following:
period = floor ( (ceil(freq/10)*10) ^ 2 * c + 0.5)
where c should be close to 0.0002044
As the columns above suggest, the numerical differences in the predicted cycle length are somewhat small, and particularly small between Afun2 and Bfun1. The biggest issues are for higher cycles, where any error gets multipled. Considering that point, two questions:
1. why the floor function? Is there a good reason to think the "real" cycle length is an integer?
2. why discard the numeric finding made by Gary Roberts which is expressed in the .00020417 and 0.433 values? Within the data he examined, they appear to have merit, and certainly are not excluded by comparison to observation.
In summary, what are the arguments from theory or observation for substituting Bfun1 for Afun2? That is a sincere question--not meant to be a rude challenge.
1. why the floor function? Is there a good reason to think the "real" cycle length is an integer?
I think that each task can only contain a contiguous set of sky-points. A non-integer period would imply that there were "mixed" WUs with sky-points from different cycles, and I don't see this is possible.
Quote:
2. why discard the numeric finding made by Gary Roberts which is expressed in the .00020417 and 0.433 values? Within the data he examined, they appear to have merit, and certainly are not excluded by comparison to observation.
In summary, what are the arguments from theory or observation for substituting Bfun1 for Afun2? That is a sincere question--not meant to be a rude challenge.
You are absolutely right, my observations do by no means justify to drop Gary's choice of constants, I just wasn't aware of how Gary got there. My focus was to verify the 10Hz step-function with some observation data, so I infact now propose to combine Gary's function with the integer-period hypothesis.
Anyway the functions are incredibly close now, I think we really got to the core of it by now.
I think that each task can only contain a contiguous set of sky-points. A non-integer period would imply that there were "mixed" WUs with sky-points from different cycles, and I don't see this is possible.
Whilst I don't claim to fully understand what you are saying here, I do agree with an integer period, probably because it "feels right" :).
Quote:
... I just wasn't aware of how Gary got there.
And here I was thinking I'd explained that to the nth degree :). I was playing with numbers until something popped out.
Quote:
My focus was to verify the 10Hz step-function with some observation data ...
Which was exactly why I was asking the dumb questions. I was contemplating how best to do that too. I have a vast range of frequencies on tap. I don't know how to do what you've done but it would seem that all I need to do is select about 5 cases where the data frequency spans a skygrid range. For example, consider a 900 skygrid. If I found hosts that were crunching approximately 891, 893, 895, 897, 899 data and could identify a precise "on period" task for each of those and the (non-zero) seq# for each of those tasks was the same (or a precise integer multiple), wouldn't that really prove it? From what you've been saying the output zip file only "hangs around" until uploaded so all I need to do is fill up with suitable tasks and then prevent uploading (suspend network access) until I've captured the zip files? Is that correct?
Alternatively, we could just go ask Bernd instead of expending all that energy. I'm rather curious as to why he hasn't put us out of our misery earlier :). Of course that would completely take away the thrill of the chase :).
Quote:
Anyway the functions are incredibly close now, I think we really got to the core of it by now.
At higher frequencies, a small delta in frequency can translate to enough of a difference in the period calculation to cause the data points to be off model line by a sufficient amount to look terrible. Also, being absolutely sure about the 10Hz step for period calculations should allow us to combine all results data from a given skygrid range and thus eliminate the multiple sparse plots from having separate 909.10, 909.15, 909.20, 909.25, .... frequency bins when using RR. This is particularly so for slower hosts which never really get a good long set of points in the one frequency bin.
Which was exactly why I was asking the dumb questions. I was contemplating how best to do that too. I have a vast range of frequencies on tap. I don't know how to do what you've done but it would seem that all I need to do is select about 5 cases where the data frequency spans a skygrid range. For example, consider a 900 skygrid. If I found hosts that were crunching approximately 891, 893, 895, 897, 899 data and could identify a precise "on period" task for each of those and the (non-zero) seq# for each of those tasks was the same (or a precise integer multiple), wouldn't that really prove it? From what you've been saying the output zip file only "hangs around" until uploaded so all I need to do is fill up with suitable tasks and then prevent uploading (suspend network access) until I've captured the zip files? Is that correct?
BoincLogX has the facility to capture the output files automatically, without disabling network access. But you have to set the monitoring interval to something pretty aggressive, otherwise the upload finishes before BoincLogX notices.
Quote:
Alternatively, we could just go ask Bernd instead of expending all that energy. I'm rather curious as to why he hasn't put us out of our misery earlier :). Of course that would completely take away the thrill of the chase :).
I bet Bernd is reading these threads, and just chortling quietly at us as we bumble around re-inventing his algorithm......
I have a vast range of frequencies on tap. I don't know how to do what you've done but it would seem that all I need to do is select about 5 cases where the data frequency spans a skygrid range. For example, consider a 900 skygrid. If I found hosts that were crunching approximately 891, 893, 895, 897, 899 data and could identify a precise "on period" task for each of those and the (non-zero) seq# for each of those tasks was the same (or a precise integer multiple), wouldn't that really prove it? From what you've been saying the output zip file only "hangs around" until uploaded so all I need to do is fill up with suitable tasks and then prevent uploading (suspend network access) until I've captured the zip files? Is that correct?
1. why the floor function? Is there a good reason to think the "real" cycle length is an integer?
I think that each task can only contain a contiguous set of sky-points. A non-integer period would imply that there were "mixed" WUs with sky-points from different cycles, and I don't see this is possible.
CU
Bikeman
Possibly, then , the floor function is in the wrong place, too early. Where you have it imposes the rather larger restriction not only that each WU must be unmixed, but that four cycles up, the integer relation must still be a multiple of the first. Could it be that the right relation is to impose the constraint of integer-ness on the final WU, rather than on the cycle?
Or, possibly, not. If I actually understood this, I'd not be asking such bumbling questions.
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:
For trough WU files the declination will be close to zero, so (say) abs(dec) < 0.3
I snagged one, just for practice, as I thought I'd seen disabling network access not work on a recent copy of BOINC, but for my 5.10.30 it worked just fine, at least for the ten minutes I need it.
The third column (declination, I understand) for h1_0904.70_S5R3__465_S5R3b_0_0 had just two distinct values in 10000 rows
0.5305701
0.5384404
The first column, which looks rather like like a frequency, took quite a few distinct values. Oddly enough, given the WU name reference to 904.70, the range of values of this column was from
904.8931027115 to
904.9092416122
They appear to take on well over a thousand distinct values, at two quite distinct density rates, one applying up to about 904.896, and a rate less than a third as great applying from there on up.
This WU, of course, it not a candidate for either peak or trough. On Afun2 basis, it is at phase .748, 32 sequence numbers above a minimum, and 43 below a peak.
Now I'll try to capture some candidate trough results, if only the work generator will make some and the scheduler send them to me.
[edited to fix an error in row count and a spurious plural]
Alternatively, we could just go ask Bernd instead of expending all that energy. I'm rather curious as to why he hasn't put us out of our misery earlier :). Of course that would completely take away the thrill of the chase :).
Quote:
I bet Bernd is reading these threads, and just chortling quietly at us as we bumble around re-inventing his algorithm......
There's probably an E@H Head Office Sweepstake riding on this, and it might have attracted serious money! Keep up the top work guys .... lookin' good. :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: OK, here is the
)
For comparison, here are the periods implied for several specific frequencies, including the ones for which you've provided observations here, according to three models proposed over time:
I've padded with annoying leading zeros to avoid even more annoying column mismatch.
freq__ _Bobs_ _Afun1 _Afun2 _Bfun1
137.50 no-obs 003.89 004.03 004.00
160.55 006.00 005.31 005.93 006.00
166.30 006.00 005.70 005.93 006.00
181.05 008.00 006.75 007.40 007.00
255.60 014.00 013.46 013.85 014.00
309.65 no-obs 019.75 019.68 020.00
335.10 024.00 023.13 023.66 024.00
578.35 069.00 068.90 068.79 069.00
641.20 086.00 084.69 086.38 086.00
662.80 092.00 090.50 091.77 092.00
662.85 092.00 090.51 091.77 092.00
699.15 100.00 100.70 100.17 100.00
699.25 100.00 100.72 100.17 100.00
705.70 103.00 102.59 103.05 103.00
732.00 112.00 110.38 111.93 112.00
751.95 118.00 116.48 118.06 118.00
775.55 124.00 123.90 124.35 124.00
845.35 no-obs 147.21 147.66 148.00
847.75 no-obs 148.05 147.66 148.00
879.15 no-obs 159.22 158.26 158.00
904.70 no-obs 168.61 169.23 169.00
Bobs: observed valued reported in your post
Afun1: predicted values by my earliest quadratic estimate: .000206*freq^2
Afun2: predicted by most recent request to Mike: 0.00020417*(Ceiling(freq,10) + 0.433)^2
Bfune1: your most recent suggestion: floor(((Ceiling(freq,10)^2)*0.0002044+0.5),1)
As the columns above suggest, the numerical differences in the predicted cycle length are somewhat small, and particularly small between Afun2 and Bfun1. The biggest issues are for higher cycles, where any error gets multipled. Considering that point, two questions:
1. why the floor function? Is there a good reason to think the "real" cycle length is an integer?
2. why discard the numeric finding made by Gary Roberts which is expressed in the .00020417 and 0.433 values? Within the data he examined, they appear to have merit, and certainly are not excluded by comparison to observation.
In summary, what are the arguments from theory or observation for substituting Bfun1 for Afun2? That is a sincere question--not meant to be a rude challenge.
RE: 1. why the floor
)
I think that each task can only contain a contiguous set of sky-points. A non-integer period would imply that there were "mixed" WUs with sky-points from different cycles, and I don't see this is possible.
You are absolutely right, my observations do by no means justify to drop Gary's choice of constants, I just wasn't aware of how Gary got there. My focus was to verify the 10Hz step-function with some observation data, so I infact now propose to combine Gary's function with the integer-period hypothesis.
Anyway the functions are incredibly close now, I think we really got to the core of it by now.
CU
Bikeman
RE: I think that each task
)
Whilst I don't claim to fully understand what you are saying here, I do agree with an integer period, probably because it "feels right" :).
And here I was thinking I'd explained that to the nth degree :). I was playing with numbers until something popped out.
Which was exactly why I was asking the dumb questions. I was contemplating how best to do that too. I have a vast range of frequencies on tap. I don't know how to do what you've done but it would seem that all I need to do is select about 5 cases where the data frequency spans a skygrid range. For example, consider a 900 skygrid. If I found hosts that were crunching approximately 891, 893, 895, 897, 899 data and could identify a precise "on period" task for each of those and the (non-zero) seq# for each of those tasks was the same (or a precise integer multiple), wouldn't that really prove it? From what you've been saying the output zip file only "hangs around" until uploaded so all I need to do is fill up with suitable tasks and then prevent uploading (suspend network access) until I've captured the zip files? Is that correct?
Alternatively, we could just go ask Bernd instead of expending all that energy. I'm rather curious as to why he hasn't put us out of our misery earlier :). Of course that would completely take away the thrill of the chase :).
At higher frequencies, a small delta in frequency can translate to enough of a difference in the period calculation to cause the data points to be off model line by a sufficient amount to look terrible. Also, being absolutely sure about the 10Hz step for period calculations should allow us to combine all results data from a given skygrid range and thus eliminate the multiple sparse plots from having separate 909.10, 909.15, 909.20, 909.25, .... frequency bins when using RR. This is particularly so for slower hosts which never really get a good long set of points in the one frequency bin.
Cheers,
Gary.
RE: Which was exactly why I
)
BoincLogX has the facility to capture the output files automatically, without disabling network access. But you have to set the monitoring interval to something pretty aggressive, otherwise the upload finishes before BoincLogX notices.
I bet Bernd is reading these threads, and just chortling quietly at us as we bumble around re-inventing his algorithm......
RE: I have a vast range
)
Yes, that sounds like a plan that would work!
CU
Bikeman
RE: RE: 1. why the floor
)
Possibly, then , the floor function is in the wrong place, too early. Where you have it imposes the rather larger restriction not only that each WU must be unmixed, but that four cycles up, the integer relation must still be a multiple of the first. Could it be that the right relation is to impose the constraint of integer-ness on the final WU, rather than on the cycle?
Or, possibly, not. If I actually understood this, I'd not be asking such bumbling questions.
RE: When the result is
)
I snagged one, just for practice, as I thought I'd seen disabling network access not work on a recent copy of BOINC, but for my 5.10.30 it worked just fine, at least for the ten minutes I need it.
The third column (declination, I understand) for h1_0904.70_S5R3__465_S5R3b_0_0 had just two distinct values in 10000 rows
0.5305701
0.5384404
The first column, which looks rather like like a frequency, took quite a few distinct values. Oddly enough, given the WU name reference to 904.70, the range of values of this column was from
904.8931027115 to
904.9092416122
They appear to take on well over a thousand distinct values, at two quite distinct density rates, one applying up to about 904.896, and a rate less than a third as great applying from there on up.
This WU, of course, it not a candidate for either peak or trough. On Afun2 basis, it is at phase .748, 32 sequence numbers above a minimum, and 43 below a peak.
Now I'll try to capture some candidate trough results, if only the work generator will make some and the scheduler send them to me.
[edited to fix an error in row count and a spurious plural]
RE: Alternatively, we could
)
There's probably an E@H Head Office Sweepstake riding on this, and it might have attracted serious money! Keep up the top work guys .... lookin' good. :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal