First search on the advanced-generation LIGO detector data
Submitted on 9 Mar 2016 14:34:10 UTC
The first E@h search on the advanced-generation LIGO detector data (O1) has started ! We are searching the sky for gravitational wave signals with frequencies between 20 Hz and 100 Hz. We have packed two searches in a single application: one for standard ever-lasting continuous gravitational waves and the other for continuous signals lasting only some days. The run was designed to last no more than a few months because we have a long list of exciting searches that we want to launch on the O1 data: we want to look at frequencies above 100 Hz and also concentrate our computing power on a few specific promising objects.
Since the last gravitational wave run we have developed a faster application that hinges on the power of the Fast Fourier Transform algorithm. There is no such thing as a free lunch so we are paying a price for this : the performance of our application depends now on the size of the cache of the volunteer computer that it is running on. In order to be able to assign credit fairly for the work done by all volunteer hosts and in order to balance well the computational load among the different hosts, we have split the work for this search in two separate runs for different host classes. A work-unit from any of these runs is equally likely to harbour a signal and both runs are crucial to the search!
M.Alessandra Papa for the E@H team
Language
Copyright © 2024 Einstein@Home. All rights reserved.
Comments
First search on the advanced-generation LIGO detector data
)
Thanks Marialessandra !
Exciting !
Bill
Wonderful news!
)
Wonderful news!
"Everything should be made as simple as possible, but not simpler." A. Einstein
Excellent news. Let's hope
)
Excellent news. Let's hope that LIGO continues to live up to a spectacular beginning!
Great news! Thanks a lot!
)
Great news! Thanks a lot!
This is great, glad to be a
)
This is great, glad to be a participant. Thank you.
http://www.nature.com/news/ci
)
http://www.nature.com/news/citizen-scientists-take-on-latest-gravitational-wave-data-1.19505
I'm looking forward to
)
I'm looking forward to crunching some data!
So I assume you are alluding
)
So I assume you are alluding to the "O1I" and "O1F" applications. If so, which is which, and what does the last position denote?
RE: So I assume you are
)
Well, F denotes "Fast" hosts and I is "I don't know, but it's all the others". ;-)
(Fast hosts are apparently those with sufficient cache for the tasks)
This is so cool !
)
This is so cool ! :-)
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: [...] the performance
)
So there's a connection between Space & Time...? :-)
E VIRGO? O i suoi dati sono
)
E VIRGO? O i suoi dati sono inglobati tra quelli di LIGO?
Ciao,
Ermanno che, decenni fa, lavorava a 50 mt da un'antenna gravitazionale (cilindro di alluminio)
I am now running on a newer
)
I am now running on a newer computer with 6GB memory. Can I assume that it has enough cache to handle this newer work or is there some adjustment needed to the properties so that it can be handled? My little desktop does indeed want to join in the crunching.
RE: I am now running on a
)
The amount of cache is dependent on what model of CPU you have (different ones are made with larger/smaller cache based on many factors like price/intended purpose/etc.). The amount of RAM memory that you mentioned is completely independent of cache.
That said, your Core i3-2130 (which is similar to my i3-4130, just a bit older) should be able to handle the "I" tasks, so it will probably get them and certainly contribute. I notice back on the 4th and 5th it completed 2 of the "tuning" tasks, so in that way, it already has. :-)
Why exactly is the updated
)
Why exactly is the updated use of the FFT require more cache size?
Also do you have an elog of your development?
RE: Why exactly is the
)
The code that does the actual search is all new and has never been used before on E@H. In previous versions we didn't use an actual FFT (like FFTW), you could think of what we did as s very narrow-band FFT (16 bins). This was highly efficient when targeting specific frequencies (and in memory terms it still is), but required a lot of "looping" when the frequency is one of the things you're looking for. The new code "resamples" the time domain data and then uses a single FFT to get the whole frequency range. This actually uses FFTW and is more efficient with a larger cache than with a smaller one. It's not that it actually requires larger caches, it just runs a lot faster.
Development of the application is done in a git repo that is publicly visible. However, it's not really obvious which changes will affect an E@H application. The application currently running is built from lalapps/src/pulsar/GCT/HierarchSearchGCT.c, the main ingredients for the actual search code are in lalpulsar/src, and technical stuff to make this a BOINC application is in lalapps/src/pulsar/EinsteinAtHome.
BM
BM
I am so very impressed. Now I
)
I am so very impressed. Now I ask this question. Why can we not explore the gravitational waves within our own solar system? Should we not be able pick up the gravitational waves better just outside of the Ort cloud.
I think they would be too
)
I think they would be too weak! Remember the only gravitational waves found so far (not by this project but in data from the same LIGO detector this project gets data from also) were determined to be caused by the collision of two black holes. So on the one hand it seems a pity we cannot detect gravitational waves within our own solar system, one the other hand we are lucky as a black hole (or other massive objects heavy enough to cause detectable gravitational waves) being so close would likely destroy our planet and turn it into the equivalent of a string of spaghetti due to the massive tidal gradient.
Also putting up detectors for
)
Also putting up detectors for gravitational waves in space is a totally valid idea that is currently being explored.
RE: I think they would be
)
Not only weak, but also have very low frequencies. Like very tiny fractions of 1 Hz. Because in our solar system we do not have any fast spinning objects of cosmic mass scale. All orbital and spinning periods lie in the range from hours to years. 1 Hr period = 0.00028 Hz. 1 day = 0.000012 Hz
And all current GW detectors is not sensitive for such low frequencies. Their working range is something like 10 - 1000 Hz.
RE: RE: I think they
)
Well, lets look at the closest object to us, the moon. Now if we built a detector that could look at those low frequencies we have a problem. Tides. As the gravitational waves would be in sync with the tides is becomes a real issue to subtract out the tidal force from the data and leave just the GW. I do strongly suspect at the distance of the moon (inverse square law) the GW energy is above the threshold of a detector, just that we haven't yet figured out how to isolate the detector from the tidal forces or how to keep our detector quiet for the month long period of the wave. I'm also not sure if the wave front would require detectors at the poles or the equator. Also we may well have to find a way to remove the earth's rotation as the arms may need to point the same way in space for such a low frequency detection. If at the poles I suppose you could build a huge lazy Susan to allow the earth to rotate under the lab!
This is probably a dumb
)
This is probably a dumb (ignorant, yes) question!?
Would not a Forward Gravitational Detector be of use here? My understanding is it is VERY sensitive.
My question is probably
)
My question is probably dumber than most... It concerns measuring the frequencies below 10 hz...
With all the issues around frequencies, revolutions, tidal forces and such, would it not be possible to build and station a GW detector in a neutral orbit in space? Of course nothing can definitively be said to be stationary except but relatively speaking. I hear people talking about isolating movements using lazy-susans at earth's poles.
I would suppose the only argument against this would be a need for maintaining the absolute positioning required for the interferometric measurements. Even so, how do they maintain the absolute positioning required for extended time-lapse photography of Hubble, Spitzer, COBE, et.al...?
Sign me, "Curious George"
-_=G.g
RE: My question is probably
)
Have you seen this thread? https://einsteinathome.org/node/196945
RE: This is probably a dumb
)
Doesn't sound like it would work here.
https://en.wikipedia.org/wiki/Robert_L._Forward
I assume this new LIGO data
)
I assume this new LIGO data is the projects highest current priority so I will turn off the other CPU work fetches.
For our einstein@home team
)
For our einstein@home team (at geopense.net), we would really like to see more crunching clients that run on the Raspberry Pi. Why? Because this $35 board has brought millions of people into the maker movement, and a sizeable number of those are also into citizen science. The GPU in the Pi is proprietary, but with the impending nvidia pascal GPU, FFT algorithms may really start to pay off. Here's the thing: the Pi has had FFT on GPU for over two years !
https://www.raspberrypi.org/blog/accelerating-fourier-transforms-using-the-gpu/
- Thomas Huxley
Any chance for a GPU version
)
Any chance for a GPU version of the new apps? They should run the FFT well. And integrated Intel GPUs would have access to unusually large caches, i.e. the CPU L3 and L4 (if present). And most importantly, from my point of view: the Skylake GPUs can't run BRP at all, probably due to driver problems, so maybe the new app could work.
MrS
Scanning for our furry friends since Jan 2002
I have two questions: 1.
)
I have two questions:
1. on the home page for GEO600 it states: GEO600 ist Teil des weltweiten Netzwerks von Gravitationswellen-Detektoren und ist derzeit der einzige Detektor, der durchgängig Messdaten aufnimmt. (GE600 is a part the world wide network of GW dectors and is at present the only detector that continuously collects mesurement data.)
Does any of this data from GEO600 find its way into the E@H analysis?
2. Both Hanford and Livingston are producing data. How is this handled by E@H, i.e. is the data handled seperately or is combined. If it is handled seperately, can one see on the data packet which is downloaded into E@H from which site the data is coming?
Thanks,
Larry
How are the estimated run
)
How are the estimated run times calculated? I recently added a CPU only host in order to process more of this data. The project sends it what appear to be twin packs because they are awarded 2K in credit. At first the estimated run time was well over 1 day when they actually take a bit over 13 hrs. Now the est. time is down to 17 h 7 m.
For a new host Boinc uses the
)
For a new host Boinc uses the benchmark and the -value sent by the server to calculate how long a task will take. As tasks complete Boinc then adjusts the DCF (Duration Correction Factor) to adjust to the actual time the tasks take and so calibrate the estimates for future tasks.
Tasks taking a shorter time than the estimate will make Boinc adjust the DCF by a bit, task taking longer than the estimate will make Boinc adjust the DCF to account for the whole difference so that future tasks will have estimates to match the long running task.
There is only one DCF per project in Boinc so running more applications from the same project can and probably will make the DCF swing up and down and so also the estimates.
Newer server software will handle the estimate calculation on the server and Boinc will then disable the use of DCF for that project. Unfortunately Einstein has yet to adopt this so we are still stuck with the use of DCF.
RE: I have two
)
In previous searches hanford data was work units starting with an 'H', Livingston data was work units starting with an 'L'. I assume this is still the case, but only have 'h' tasks on my PCs at present. GEO600 data was never sent out to E@H because the detector, due to its smaller size, is significantly less sensitive despite having equivalent hardware installed.
RE: Does any of this data
)
That data is not processed by E@H volunteers. I believe it is processed 'in house' using the Atlas supercomputer.
The data is provided in pairs of files at a particular frequency. The two members of a 'pair' come from the two observatories. A data file starting h1_... has come from Hanford and the corresponding l1_... has come from Livingston. The app that you use for crunching a single task will be processing the data in (usually) 6 pairs of files with closely related frequencies. There are a large number of tasks that can use the same 6 pairs of data files - this is the essence of locality scheduling.
Here is a complete example, chosen from one of my machines. It happens to come from the 'F' series. It's quite similar for 'I' with just small differences in the names:-
[pre]Full task name: h1_0090.45_O1C01Cl2In3__O1AS20-100F_90.55Hz_2380_0
Workunit name: h1_0090.45_O1C01Cl2In3__O1AS20-100F_90.55Hz_2380
Large data files - pair 1: h1_0090.45_O1C01Cl2In3.we4j l1_0090.45_O1C01Cl2In3.we4j
Large data files - pair 2: h1_0090.50_O1C01Cl2In3.ljGc l1_0090.50_O1C01Cl2In3.ljGc
Large data files - pair 3: h1_0090.55_O1C01Cl2In3.Gxec l1_0090.55_O1C01Cl2In3.Gxec
Large data files - pair 4: h1_0090.60_O1C01Cl2In3.ddDA l1_0090.60_O1C01Cl2In3.ddDA
Large data files - pair 5: h1_0090.65_O1C01Cl2In3.nUUp l1_0090.65_O1C01Cl2In3.nUUp
Large data files - pair 6: h1_0090.70_O1C01Cl2In3.x34r l1_0090.70_O1C01Cl2In3.x34r[/pre]
Some points about the above.
* The scheduler sends out two copies initially. These are the primary tasks and they have extensions to the workunit name (_0 and _1) to form their task name. If either of these two fail, further identical copies (_2, _3, _4, etc) are sent out to replace failed tasks, as necessary. A workunit will be completed when there are two successful tasks in agreement with each other returned and processed by the validator.
* A task is just a set of parameters which is interpreted by the app. Each computer receiving a copy of a task also needs the complete set of 12 large data files (and other standard files) that the set of parameters will point to.
* Both the workunit name and the task name have a 'sequence' number attached - _2380 in the above example. This number is just a position in a sequence from some high starting number all the way down to zero. The full sequence represents all the tasks that will use exactly the same set of large data files. The scheduler issues tasks in reverse numerical order so when you see sequence numbers getting down towards zero, you know that the tasks for that particular sequence are just about all issued. If we call the above example the "90.45Hz set or sequence", it's very convenient for the scheduler to also give you tasks for the adjacent sequence - 90.50Hz. For tasks in this sequence, you could use 10 out of the previous 12 data files and just add two new ones, h1_0090.75_.... and l1_0090.75_.... - a very minimal extra download.
* At any one time, the workunit generator keep just a small number of tasks in each sequence. This small number can quickly (just temporarily) run out if a host asks for a lot of tasks (or several hosts ask almost simultaneously). In this case you will be switched to an adjacent sequence (0.05Hz apart) for the balance of tasks needed. For this reason, a fast multicore machine can have several adjacent sequences 'on the go' at one time. When more work is generated, a depleted sequence will be 'topped up' again. The scheduler will always try to give you work for the data files you have - locality scheduling.
* For low frequency sequences (e.g. 20Hz) the number of tasks in a full sequence is relatively small - just a few hundred. This number becomes progressively larger as the frequency increases. Above 90Hz, as in the above example, the number of tasks is around 2,500 or more.
Cheers,
Gary.
Thank both of you for the
)
Thank both of you for the detailed information!
Larry
I'm going to buy a new comp.
)
I'm going to buy a new comp. Will be HP ProBook 450 G2 suitable for "F"? Thanks for advice. Honza
RE: I'm going to buy a new
)
No, as per Christian's post here no Intel i3 processors can get the "F" tasks, they can get the "I" tasks that are equally important.
Thanks for your answer, but
)
Thanks for your answer, but HP ProBook 450 G2 contains Intel Core i5 5200U. What about this processor? Thanks. Honza
Hi Alessandra, what size has
)
Hi Alessandra, what size has to have cashe for FFT tasks please? Honza
Hi Honza, I don't know what
)
Hi Honza, I don't know what you mean by "cashe for FFT tasks". Did you see the FAQ on the O1AS search? I think it should answer your question when FFT tasks mean O1AS20-100F tasks.
After processing a big chunk
)
After processing a big chunk of the current available data, are there already some indications that something interesting might have been found.