Well, I can't speak officially, since I'm not on the PALFA team, but if I read this page correctly, there may be 3 new millisecond pulsars that have been discovered this year, most likely by one of us unless there's additional processing going on.
"Better is the enemy of the good." - Voltaire (should be memorized by every requirements lead)
Well, I can't speak officially, since I'm not on the PALFA team, but if I read this page correctly, there may be 3 new millisecond pulsars that have been discovered this year, most likely by one of us unless there's additional processing going on.
The pulsars on the PALFA page were not discovered by the Einstein@Home search. If Einstein@Home discoveres something new you can be sure to read something about this on the Einstein@Home webpage :)
There are other processing sites in the PALFA collaboration looking at the PALFA survey data that detect new pulsars from time to time. Out of all these processing sites Einstein@Home has a unique and unprecedented sensitivity to pulsars in tight binary systems. That means that Einstein@Home can see not only the sources all other processing sites will see but also the sources the other processing sites are very likely to miss because they are too weak to be detected with their data analysis methods. Then, however it depends on how the data are distributed among the sites whether Einstein@Home gets one of the "lucky" data sets with a new pulsar in it.
Out of all these processing sites Einstein@Home has a unique and unprecedented sensitivity to pulsars in tight binary systems. That means that Einstein@Home can see not only the sources all other processing sites will see but also the sources the other processing sites are very likely to miss because they are too weak to be detected with their data analysis methods.
Thank you for the information :) How does Einstein@Home's sensitivity compare to the other methods for other types of systems? Are there any particular weaknesses to its analysis? (in terms of things it was not designed to look for in the first place, that is)
How does Einstein@Home's sensitivity compare to the other methods for other types of systems? Are there any particular weaknesses to its analysis? (in terms of things it was not designed to look for in the first place, that is)
Einstein@Home's analysis method can detect everything the other processing sites see with the same or better sensitivity. This is due to the fact that our search is a complete (non-approximate) correction of the Doppler effect in binary systems. The methods used elsewhere do not correct for Doppler effect at all or only approximately so that the correction only works for orbital periods that are long compared to the observation time.
How does Einstein@Home's sensitivity compare to the other methods for other types of systems? Are there any particular weaknesses to its analysis? (in terms of things it was not designed to look for in the first place, that is)
Einstein@Home's analysis method can detect everything the other processing sites see with the same or better sensitivity. This is due to the fact that our search is a complete (non-approximate) correction of the Doppler effect in binary systems. The methods used elsewhere do not correct for Doppler effect at all or only approximately so that the correction only works for orbital periods that are long compared to the observation time.
Cheers, Ben
As described in this tutorial, the processing method of the E@H search uses a new algorithm to search for pulsars in tight binary systems where the nonlinear Doppler shifts would tend to smear the pulses across numerous search bins of other algorithms, lessening their sensitivity. Naturally as part of the Monte Carlo sampling of potential orbits, the E@H processing does test relatively benign orbits as well as the radical ones. Therefore, the E@H processing is at least as sensitive as any other method out there, and will possibly detect a binary pulsar that other processing (even on the same data set) will miss. Its only downside is that it consumes far more FLOPS than the other methods...that's why only the supercomputing available cheaply with E@H makes it reasonable to try. Somewhere there is a poster paper with more of the gory details but I lost the link.
"Better is the enemy of the good." - Voltaire (should be memorized by every requirements lead)
ABP1 workunit generation has been stopped. The purpose is to test the behavior of the project when there is no ABP work. This means that the ABP1 WUG will stay offline until we don't have any unsent ABP results left and clients will only get S5R6 work.
If issues show up that we can't fix immediately, we'll start the ABP1 work generation again. If, however, all goes well and the project keeps functioning, instead we'll generate and send out the first ABP2 tasks, and the ABP1 WUG will probably never be started again.
ABP2 will perform the same search on the same data as ABP1 currently does. But due to code optimizations and a smaller template bank it does this much faster; also ABP2 results don't validate against ABP1 ones, so we set up a new 'application'. We expect the ABP2 WUs to take ~1/5 of the time of ABP1 WUs.
Note that people that manually opted out of ABP1 in the project preferences will need to do the same for ABP2 (they already can).
We expect the ABP2 WUs to take ~1/5 of the time of ABP1 WUs.
Let's hope there will be readjustment to the WU/processor/day cache for ABP2s enough to cater 1/5 the time of complete ABP1 WUs. On a full day cache of 256 WUs, my tower can gobble them up in 3.2 days. Hence 1/5 the time means the same amount of ABP2 WUs in less than 16 hours....?
We expect the ABP2 WUs to take ~1/5 of the time of ABP1 WUs.
Let's hope there will be readjustment to the WU/processor/day cache for ABP2s enough to cater 1/5 the time of complete ABP1 WUs. On a full day cache of 256 WUs, my tower can gobble them up in 3.2 days. Hence 1/5 the time means the same amount of ABP2 WUs in less than 16 hours....?
Hi!
Indeed, the maximum number of WUs per day and core will be increased (to 32 AFAIK).
RE: Hello! On page
)
Well, I can't speak officially, since I'm not on the PALFA team, but if I read this page correctly, there may be 3 new millisecond pulsars that have been discovered this year, most likely by one of us unless there's additional processing going on.
"Better is the enemy of the good." - Voltaire (should be memorized by every requirements lead)
RE: Well, I can't speak
)
The pulsars on the PALFA page were not discovered by the Einstein@Home search. If Einstein@Home discoveres something new you can be sure to read something about this on the Einstein@Home webpage :)
There are other processing sites in the PALFA collaboration looking at the PALFA survey data that detect new pulsars from time to time. Out of all these processing sites Einstein@Home has a unique and unprecedented sensitivity to pulsars in tight binary systems. That means that Einstein@Home can see not only the sources all other processing sites will see but also the sources the other processing sites are very likely to miss because they are too weak to be detected with their data analysis methods. Then, however it depends on how the data are distributed among the sites whether Einstein@Home gets one of the "lucky" data sets with a new pulsar in it.
Cheers, Ben
Einstein@Home Project
RE: Out of all these
)
Thank you for the information :) How does Einstein@Home's sensitivity compare to the other methods for other types of systems? Are there any particular weaknesses to its analysis? (in terms of things it was not designed to look for in the first place, that is)
RE: How does
)
Einstein@Home's analysis method can detect everything the other processing sites see with the same or better sensitivity. This is due to the fact that our search is a complete (non-approximate) correction of the Doppler effect in binary systems. The methods used elsewhere do not correct for Doppler effect at all or only approximately so that the correction only works for orbital periods that are long compared to the observation time.
Cheers, Ben
Einstein@Home Project
Wow, that's great. Doing some
)
Wow, that's great. Doing some really worthwhile crunching here :)
RE: RE: How does
)
As described in this tutorial, the processing method of the E@H search uses a new algorithm to search for pulsars in tight binary systems where the nonlinear Doppler shifts would tend to smear the pulses across numerous search bins of other algorithms, lessening their sensitivity. Naturally as part of the Monte Carlo sampling of potential orbits, the E@H processing does test relatively benign orbits as well as the radical ones. Therefore, the E@H processing is at least as sensitive as any other method out there, and will possibly detect a binary pulsar that other processing (even on the same data set) will miss. Its only downside is that it consumes far more FLOPS than the other methods...that's why only the supercomputing available cheaply with E@H makes it reasonable to try. Somewhere there is a poster paper with more of the gory details but I lost the link.
"Better is the enemy of the good." - Voltaire (should be memorized by every requirements lead)
RE: Somewhere there is a
)
I guess the poster you have in mind is linked on the page of the "Amaldi 8" conference:
http://sites.google.com/site/amaldi8posters1/posters
It's actually Ben's own poster :-).
CU
Bikeman
ABP1 workunit generation has
)
ABP1 workunit generation has been stopped. The purpose is to test the behavior of the project when there is no ABP work. This means that the ABP1 WUG will stay offline until we don't have any unsent ABP results left and clients will only get S5R6 work.
If issues show up that we can't fix immediately, we'll start the ABP1 work generation again. If, however, all goes well and the project keeps functioning, instead we'll generate and send out the first ABP2 tasks, and the ABP1 WUG will probably never be started again.
ABP2 will perform the same search on the same data as ABP1 currently does. But due to code optimizations and a smaller template bank it does this much faster; also ABP2 results don't validate against ABP1 ones, so we set up a new 'application'. We expect the ABP2 WUs to take ~1/5 of the time of ABP1 WUs.
Note that people that manually opted out of ABP1 in the project preferences will need to do the same for ABP2 (they already can).
BM
BM
RE: We expect the ABP2 WUs
)
Let's hope there will be readjustment to the WU/processor/day cache for ABP2s enough to cater 1/5 the time of complete ABP1 WUs. On a full day cache of 256 WUs, my tower can gobble them up in 3.2 days. Hence 1/5 the time means the same amount of ABP2 WUs in less than 16 hours....?
RE: RE: We expect the
)
Hi!
Indeed, the maximum number of WUs per day and core will be increased (to 32 AFAIK).
happy crunching
Bikeman