* Also under investigation is whether and how to possibly add a "vetoing" already in the application that could filter out e.g. known instrumental artifacts. Currently this is done later in post processing. As a limiting factor on the sensitivity of the search is the number of candidates we can send back from the clients, eliminating candidates before sending them back might therefore increase the sensitivity of the search, too. One unwanted side-effect of this vetoing would be that the run-time of a given task becomes data-dependent and less predicable.
How many of the 10k results returned are typically rejected as instrument noise on the server?
How many of the 10k results returned are typically rejected as instrument noise on the server?
In principle after the tasks were processed by Einstein@home all candidates are thrown into larger pools of frequency bands, then these pools are filtered by various criteria.
Instrumental lines that are known at the time of data preparation (i.e. when the data files for E@H processing are produced) are already removed from the data at that time, but usually a couple of noise sources and processing artifacts are discovered later by processing the detector data in various pipelines.
It's pretty hard to break this down to individual tasks. I'd guess the overall "reject rate" due to instrumental noise might be 1 in 10.000, which would mean one per task on average. But don't count on my rough guess, read the paper when it's published (this may take a while, though).
The "S6Bucket" application is essentially the same as what we were using since S5GCE. The main difference is not in the application, but in the data that we search for gravitational waves. Previously we used data from the fifth science run of the LIGO instruments (hence the "S5" at the beginning). For S6Bucket we are using data from the sixth science run.
The usable data from S6 is way fewer than what we could use from S5. So searching S6 data lowers the requirements for download volume, disk space and application memory compared to previous runs.
A slight change that you might also notice is some delay at the end of a task. The application will keep running for a few minutes after it reached the 100% mark. During this time we are doing some smaller calculations ("LineVeto") that we may use in a future run to increase the sensitivity. Currently this is experimental and only done for verification of the algorithm.
Another, even more technical issue is that the "incoherent" part of the application code has been sped up a lot (roughly by a factor of four) due to vectorization that Bikeman did for us. Due to the setup of the new workunits, the overall runtime of a S6Bucket task should still be roughly the same as what you are used to from S5GC1HF. But if you would calculate a S5GC1HF task with the S6Bucket application, you would notice quite a speedup.
I wonder how are used the calculated data of my computer.
My quad-core CPU turns in 100% with the GPU..24h/24h. Every 4 tasks are calculated in 18 hours
I would like to know if discoveries were made
I do not use my PC, but it warms the house And the ventirad shouts in the scandal
i hope it is usefull ...
A slight change that you might also notice is some delay at the end of a task. The application will keep running for a few minutes after it reached the 100% mark. During this time we are doing some smaller calculations ("LineVeto") that we may use in a future run to increase the sensitivity. Currently this is experimental and only done for verification of the algorithm.
BM
An idea to consider: Calculate the average percentage of the work done before the LineVeto section starts. Then have the main section of the application reach only a progress corresponding to this percentage, and write a final checkpoint before the LineVeto section starts. The LineVeto section can then jump to 100% progress when it finishes, if it does not have checkpoints.
RE: * Also under
)
How many of the 10k results returned are typically rejected as instrument noise on the server?
RE: How many of the 10k
)
In principle after the tasks were processed by Einstein@home all candidates are thrown into larger pools of frequency bands, then these pools are filtered by various criteria.
Instrumental lines that are known at the time of data preparation (i.e. when the data files for E@H processing are produced) are already removed from the data at that time, but usually a couple of noise sources and processing artifacts are discovered later by processing the detector data in various pipelines.
It's pretty hard to break this down to individual tasks. I'd guess the overall "reject rate" due to instrumental noise might be 1 in 10.000, which would mean one per task on average. But don't count on my rough guess, read the paper when it's published (this may take a while, though).
BM
BM
RE: Would you like to the
)
Sorry, could you rephrase your question?
BM
BM
RE: RE: Would you like to
)
I ask if you can explain what this new application of a simple, thank you
The "S6Bucket" application is
)
The "S6Bucket" application is essentially the same as what we were using since S5GCE. The main difference is not in the application, but in the data that we search for gravitational waves. Previously we used data from the fifth science run of the LIGO instruments (hence the "S5" at the beginning). For S6Bucket we are using data from the sixth science run.
The usable data from S6 is way fewer than what we could use from S5. So searching S6 data lowers the requirements for download volume, disk space and application memory compared to previous runs.
A slight change that you might also notice is some delay at the end of a task. The application will keep running for a few minutes after it reached the 100% mark. During this time we are doing some smaller calculations ("LineVeto") that we may use in a future run to increase the sensitivity. Currently this is experimental and only done for verification of the algorithm.
Another, even more technical issue is that the "incoherent" part of the application code has been sped up a lot (roughly by a factor of four) due to vectorization that Bikeman did for us. Due to the setup of the new workunits, the overall runtime of a S6Bucket task should still be roughly the same as what you are used to from S5GC1HF. But if you would calculate a S5GC1HF task with the S6Bucket application, you would notice quite a speedup.
Does this answer your question?
BM
BM
I wonder how are used the
)
I wonder how are used the calculated data of my computer.
My quad-core CPU turns in 100% with the GPU..24h/24h. Every 4 tasks are calculated in 18 hours
I would like to know if discoveries were made
I do not use my PC, but it warms the house And the ventirad shouts in the scandal
i hope it is usefull ...
Best regards
RE: A slight change that
)
An idea to consider: Calculate the average percentage of the work done before the LineVeto section starts. Then have the main section of the application reach only a progress corresponding to this percentage, and write a final checkpoint before the LineVeto section starts. The LineVeto section can then jump to 100% progress when it finishes, if it does not have checkpoints.
when i suspends the works,
)
when i suspends the works, those who are ready to validate are not sent
Why ?
thanks
I noticed the s6bucket use
)
I noticed the s6bucket use allot less memmory, that's nice.
Also the write to disk feels less.
This is rlly an issue with dual triple quadcore , because you double triple quadruple the memmory then.
Ps: we hear some discoveries with the binary project, not with this project witch is to understand.
But how about some technical updates
RE: when i suspends the
)
It may be waiting for you to click on the Update button, or simply wait for the normal time to return the more slowly completed workunits.