A couple of things didn't really go to plan, so here's an updated one:
* The last remaining workunit of "O1OD1" just got a canonical result, so this run is officially ended. I'll leave the validator etc. running for a few days such that the 23 tasks remaining "in progress" can get credited if they are reported on time.
* The "engineering run" "O1OD1E" has ended in the sense that no more new workunits are generated. However there are still some tasks (~60k) left to be ran. These will all be ran by CPU App versions to validate the results from the GPU versions that were already reported. You won't get any "O1OD1E" tasks for a GPU anymore. Remember that validation of the GPU results by CPU was the original purpose of this run. To speed this up, I promoted the CPU version 0.07 out of Beta test status.
Feeding the remaining O1OD1E tasks through the "locality scheduler" interferes badly with delivering the O2AS tasks, therefore I made O1OD1 a "normal (array) scheduling" App. This means that for the remaining O1OD1E tasks your download volume per task may increase (which is the case at the end of a "locality scheduling run anyway). If you don't like that, you may opt-out of O1OD1E.
* The O2AS run (CPU only) has been switched from a "fixed quorum of 2" to "adaptive replication". Removing its competitor "O1OD1E" from the "locality scheduling" applications should make getting O2AS tasks much easier.
* There are additional checks to be ran on the data of the planned "injection run" (likely named "O1OD1I"), the successor to O1OD1E. This will postpone its launch to next week.
Given the lack of new gravity waves, which is my main interest in this project. I will have to make a decision. Do I allow my Einstein host fall back on it's back up project or restart looking for pulsars and watch my RAC grow?
If this is the biggest problem I have my life is pretty good.
LIGO discovered 2 more in the 1st 2 weeks after starting back up.
Given the lack of new gravity waves, which is my main interest in this project. I will have to make a decision. Do I allow my Einstein host fall back on it's back up project or restart looking for pulsars and watch my RAC grow?
If this is the biggest problem I have my life is pretty good.
LIGO discovered 2 more in the 1st 2 weeks after starting back up.
What exactly is a 'massgap' detection? One of the 6 candidates they're not sure what was, and are currently listing it as a 24% probability of being a massgap, whatever that is.
Massgap is a range on the mass scale for which there is no current evidence for any black holes ( or neutron stars ). One mass gap is b/w about 2 to 5 solar masses. Another is the prediction of a dearth of black holes b/w about 50 to 130 solar masses.
That's not to say there aren't objects in any mass-gap range(s), is just that none have been found to date. I guess the theorists, when generally considering the evolution of star systems, would like to know population statistics like : what fraction of BHs are b/w certain mass limits. Any modelling would have to account for mass gaps ie. why don't objects form ( or not radiate if they do ) in said gaps.
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
A couple of things didn't really go to plan, so here's an updated one:
* The last remaining workunit of "O1OD1" just got a canonical result, so this run is officially ended. I'll leave the validator etc. running for a few days such that the 23 tasks remaining "in progress" can get credited if they are reported on time.
* The "engineering run" "O1OD1E" has ended in the sense that no more new workunits are generated. However there are still some tasks (~60k) left to be ran. These will all be ran by CPU App versions to validate the results from the GPU versions that were already reported. You won't get any "O1OD1E" tasks for a GPU anymore. Remember that validation of the GPU results by CPU was the original purpose of this run. To speed this up, I promoted the CPU version 0.07 out of Beta test status.
Feeding the remaining O1OD1E tasks through the "locality scheduler" interferes badly with delivering the O2AS tasks, therefore I made O1OD1 a "normal (array) scheduling" App. This means that for the remaining O1OD1E tasks your download volume per task may increase (which is the case at the end of a "locality scheduling run anyway). If you don't like that, you may opt-out of O1OD1E.
* The O2AS run (CPU only) has been switched from a "fixed quorum of 2" to "adaptive replication". Removing its competitor "O1OD1E" from the "locality scheduling" applications should make getting O2AS tasks much easier.
* There are additional checks to be ran on the data of the planned "injection run" (likely named "O1OD1I"), the successor to O1OD1E. This will postpone its launch to next week.
Will the O1OD1E for CPU be available to both Windows and Linux machines? I turned off my Windows machine after I stopped getting O1OD1E GPU work units. If it's available for both OS then turn back on the Windows one and bring over a Linux as well to help run through the remaining work load.
Edit...
Took me a couple of times re-reading that to get it clear in my head. OK, so both OS are supported. Since both O1OD1E and O2AS are CPU now, which one gets priority in the downloads? Or should I just deselect O2AS to allow the O1OD1E priority to the CPU threads? I know you probably explained it in your posted but it's late and I'm having trouble keeping focus. Off to bed, maybe in the morning it will make more sense.
A couple of things didn't
)
A couple of things didn't really go to plan, so here's an updated one:
* The last remaining workunit of "O1OD1" just got a canonical result, so this run is officially ended. I'll leave the validator etc. running for a few days such that the 23 tasks remaining "in progress" can get credited if they are reported on time.
* The "engineering run" "O1OD1E" has ended in the sense that no more new workunits are generated. However there are still some tasks (~60k) left to be ran. These will all be ran by CPU App versions to validate the results from the GPU versions that were already reported. You won't get any "O1OD1E" tasks for a GPU anymore. Remember that validation of the GPU results by CPU was the original purpose of this run. To speed this up, I promoted the CPU version 0.07 out of Beta test status.
Feeding the remaining O1OD1E tasks through the "locality scheduler" interferes badly with delivering the O2AS tasks, therefore I made O1OD1 a "normal (array) scheduling" App. This means that for the remaining O1OD1E tasks your download volume per task may increase (which is the case at the end of a "locality scheduling run anyway). If you don't like that, you may opt-out of O1OD1E.
* The O2AS run (CPU only) has been switched from a "fixed quorum of 2" to "adaptive replication". Removing its competitor "O1OD1E" from the "locality scheduling" applications should make getting O2AS tasks much easier.
* There are additional checks to be ran on the data of the planned "injection run" (likely named "O1OD1I"), the successor to O1OD1E. This will postpone its launch to next week.
BM
Betreger wrote:Given the lack
)
LIGO discovered 2 more in the 1st 2 weeks after starting back up.
Event database:
https://gracedb.ligo.org/latest/
mmonnin wrote:Betreger
)
What exactly is a 'massgap' detection? One of the 6 candidates they're not sure what was, and are currently listing it as a 24% probability of being a massgap, whatever that is.
https://gracedb.ligo.org/superevents/S190426c/view/
Massgap is a range on the
)
Massgap is a range on the mass scale for which there is no current evidence for any black holes ( or neutron stars ). One mass gap is b/w about 2 to 5 solar masses. Another is the prediction of a dearth of black holes b/w about 50 to 130 solar masses.
That's not to say there aren't objects in any mass-gap range(s), is just that none have been found to date. I guess the theorists, when generally considering the evolution of star systems, would like to know population statistics like : what fraction of BHs are b/w certain mass limits. Any modelling would have to account for mass gaps ie. why don't objects form ( or not radiate if they do ) in said gaps.
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
Bernd Machenschalk wrote:A
)
Will the O1OD1E for CPU be available to both Windows and Linux machines? I turned off my Windows machine after I stopped getting O1OD1E GPU work units. If it's available for both OS then turn back on the Windows one and bring over a Linux as well to help run through the remaining work load.
Edit...
Took me a couple of times re-reading that to get it clear in my head. OK, so both OS are supported. Since both O1OD1E and O2AS are CPU now, which one gets priority in the downloads? Or should I just deselect O2AS to allow the O1OD1E priority to the CPU threads? I know you probably explained it in your posted but it's late and I'm having trouble keeping focus. Off to bed, maybe in the morning it will make more sense.