598 karma · joined June 13, 2017
a) Massive data volumes (~100 Gb - 1 Pb/project)
ai) This means that data is typically stored on limited access machines like HPC clusters
bi) This also means that shipping this data around is financially expensive, and cannot be supported purely by small client machines
b) A low number of seeders; scientific data is not exactly popular, and there may be network restrictions on uploads through the typically used networks;c) The requirement for a data legacy; torrents are fantastic for ephemeral data (e.g. operating system builds), but are terrible for data that must be archived and kept for potentially decades to centuries.
For part b) you are completely incorrect in your assumptions here. The majority of the cost and effort of telescopes is really in the instrumentation (the 'cameras' that are strapped to the back of the telescope). To get the most out of an observing facility, we need access to these to change them, fix them, and improve them. This is not possible with a space-based mission.
Your comment about a numerical gravitational simulation being 'wrong' because of chaos may be true on an individual resolution element level, yes, but our simulations are made up of many billions of individual particles. Like traditional CFD simulations we can also demonstrate some level of convergence.
Odd that they did not mention these when discussing sub-grid modelling, as afaik these Astronomy simulations (along with planetary impacts) are probably some of the first to have used them…
Consider this: student at institution A (UK) writes code, postdoc at institution B (USA) modifies it, shared with researcher at institution C (China) who runs it for a paper first-authored by student at institution D (Germany).
Who has the rights to share the code and data? Which jurisdiction would this fall under?
I agree generally with data and code sharing policies (all of my recent papers include zenodo deposits of data, and I work on a large open source simulation code). However, there are some serious issues here:
1. Code licensing is not always clear. Sometimes you are working with a code that some PhD student wrote, who left the field, whose advisor shared it with you. Can you share this code? Not necessarily... but this problem will go away with time.
2. Some codes include proprietary components, and chopping them out can make the code inoperable (or useless). One notable instance of this is a very famous hydro code that was used to produce predictions for nukes, that was then repurposed for running simulations of planetary collisions.
3. Sharing data is prohibitive, and if you don't have the data having the code might not really help. Our projects can produce Pbs of data, costing 10s-100s Ms of CPU hours, and as such making the data open source can be really tricky. This then means you can only share a selection of runs. On the other hand, even if you had the code, you can't reproduce a lot of the results, because of the cost of running the simulations... This actually will get _worse_ over time as we run bigger and bigger simulations.
Having labs is not equal to having bioweapons
https://twitter.com/nick_beauchamp/status/147355576211076710...
For your point 1, this is a smoothed average. I suppose they should have used wider bins, but "failing the eyeball test" doesn't say much. The point isn't to fit the data, but to collate it so that you can clearly see the overall pattern.
There's the additional prior here that we know there were significant increases in COVID infection at the same time, which has a well-studied symptom of loss of taste and smell, that nicely correlates with these.
SpaceX is an environmental disaster that I guarantee we will look back on in 50 years as the company that kick-started kessler syndrome.
They have already, objectively, caused huge environmental light-pollution based damage.
I also think that journals are too expensive, but that's why I only publish in society journals.