Accept no imitations

So I've gone from being swamped with writing a grant application to being swamped with writing an observing proposal. Yay. But I had to read this paper, because a) it's just a letter so it's nice and short and b) it's all my favourite topics mashed together.

This paper looks at a remarkable object in a compact group of galaxies. There are several big, dramatic galaxies present, with shell-like structures and arms and stars flying everywhere, but that's not what the authors are interested in. Instead, they pick on an innocuous-looking blue blob, a structureless starball peeping out from behind one of the bigger beasts. It was previously noted as being at the end of an HI tail, so the obvious idea is that it's a tidal dwarf galaxy formed from of the torn-out gas from some galaxy-galaxy interaction.

Tidal dwarf galaxies are pretty interesting in themselves, but the properties of this one overlap with not one but two other interesting objects. I guess that cubes it interestingness, making it so interesting that everyone had better had a lie down lest they get too excited.

While the smooth, structureless nature of the object isn't anything special, its stellar population seems to be wholly young : 60 Myr or less. Most "normal" galaxies have at least some very old stellar component at least a few gigayears old, even those that are dominated by a younger crowd. And this little galaxy doesn't have many stars either : so much so that it easily counts as a Ultra Diffuse Galaxy.

"Ahah !" you may be thinking. "That means UDGs are probably just tidal after all, so we can put all this hoo-hah about whether they're massive, dark-matter dominated galaxies to rest and get on with our lives."

In fact you can't. For one, UDGs are diverse enough that we know we can't paint them all with the same brush anyway. For another, this particular tidal UDG appears to be dark matter dominated, by a factor 3-10. And that's not at all expected for tidal dwarf galaxies, which are supposed to be made of purely baryonic matter.

And it gets stranger still. Given that there appears to be no ongoing star formation this object, based on UV data, the authors calculate that it will become totally invisible in about 2 Gyr. So although it's merely a faint galaxy right now, eventually it will become a truly dark galaxy. The implication, of course, is that many other such objects could already have been produced, so they're floating freely around the place confusing all kinds of hapless radio astronomers. See, there's been lots of speculation about how HI clouds can appear to masquerade as dark galaxies, where the dynamics indicates a lot of extra mass present that isn't actually there. But this object shows that there could be some such "fake" dark galaxies which really are... dark... galaxies...

This is all a lot like the idea of faking the Moon landing on the actual Moon. Or if you want a more colourful philosophical conundrum, boobs. Are they still real if they're fake ? No, don't answer that.

What they really mean is that the idea of dark galaxies is that they're supposed to explain the missing satellite problem, wherein too few galaxies are observed compared to simulations. If most of them are just too faint to see, problem solved. These would be primordial dark galaxies. But now this little object suggests we may have genuine dark galaxies produced by an entirely different, much later mechanism that would have nothing to do with the cosmological difficulties at all. So that's an extra large spanner thrown in the works. Yay.

Personally I'm not entirely sure how secure their mass estimate really is. The line width of the object is quite narrow and the inclination correction must be difficult; the HI and optical centres are offset. I also don't understand their statement that the object could become self-bound even without dark matter : they say there's a mass threshold for this, but this must surely be dependent on other factors too.  And I don't understand how you could get such large amounts of dark matter in a tidal dwarf anyway; in simulations, it tends to disperse very easily. So this object potentially raises a lot more questions than it solves - as all good discoveries should. Hurrah !

A diffuse tidal dwarf galaxy destined to fade out as a "dark galaxy"

Assuming that the object is dynamically stable and able to survive in the future, its fading in time via the aging of its stellar component will make it undetectable in optical observations in just ∼2 Gyr of evolution, even in the deepest current or future optical surveys. Its high HI mass and future undetectable stellar component will make the object match the observational properties of dark galaxies, that is, dark matter halos that failed to turn gas into stars. Our work presents further observational evidence of the feasibility of HI tidal features becoming fake dark galaxies.

The pendulum swings and swings again

The saga of NGC 1052-DF2 and DF4 continues.

I'm not going to try and keep up with every development on this one any more because there are just too many. In brief, two galaxies were found that apparently had no dark matter at all. Given their apparent distance of about 20 Mpc, their size and velocity dispersion appear to indicate that their stars are moving so slowly that they could be gravitationally bound all by themselves, with no need of the usual extra mass.

This discovery has been controversial. First there were claims that the velocity dispersions had been measured incorrectly. This never looked terribly convincing, and indeed that idea has gone away. Then there were claims that the distance was wrong. If the galaxy is actually at about 13 Mpc, then the velocity measurements actually do require quite a lot of dark matter, as well as explaining other anomalies like the brightness of the galaxy's globular clusters. This has turned into a game of galactic ping-pong, with each team periodically refuting the other's distance claims with new data or analysis methods.

The present paper is the latest in a long series of attempts to decisively knock out the claim for a 13 Mpc distance. They use the "tip of the red giant branch" method to estimate the distance. Basically, red giant stars ought to be reasonably good standard candles (at least statistically if not individually), meaning that you know their true brightness so can get the corresponding distance. Previous claims using this method, they say, were not deep enough to detect stars at 20 Mpc distances, leading to all sorts of complications in the analysis. So they've gone and got Hubble data which should be more than sufficient to sort this out. If nothing else, their main image is certainly very pretty.

They say the distance to DF2 is actually even slightly higher than their initial claim, at 22 Mpc. DF4 they've previously said is at 20 Mpc, and though there are certainly some errors in all this, they say this is sufficient to say that at least one of them isn't part of the NGC 1052 group. That's significant, because it makes a tidal formation scenario all the less likely. In addition, they mention that they have wide-field deep imaging (not presented here) which does not show the previously-reported tidal tails, so those features are likely spurious.  

Finally, they'd previously made a boo-boo in claiming that these objects refute MOND, because MOND has an external field effect that they didn't account for. But now it looks like both DF2 and DF4 are too far away from their companion galaxies for this to be significant after all. Well, we'll see. Expect lots of angry responses from both standard model and MOND enthusiasts on this one.

A Tip of the Red Giant Branch Distance of 22.1 Mpc to the Dark Matter Deficient Galaxy NGC1052-DF2 from 40 Orbits of Hubble Space Telescope Imaging

The inferred distance is DTRGB=22.1 Mpc, consistent with the previous surface brightness fluctuation distances to the bright elliptical galaxy NGC1052. The new HST distance rules out the idea that some of NGC1052-DF2's unusual properties can be explained if it were at 13 Mpc; instead, it implies that the galaxy's globular clusters are even more luminous than had been derived using the previous distance of 20 Mpc. The distance from NGC1052-DF2 to NGC1052-DF4 is well-determined at 2.1 Mpc, significantly larger than the virial diameter of NGC1052. We discuss the implications for formation scenarios of the galaxies and for the external field effect, which has been invoked to explain the intrinsic dynamics of these objects in the context of modified Newtonian dynamics.

The tale of a tiny, farting, blushing dwarf

Who amongst us doesn't have the decency to look embarrassed when publicly expelling gas ? Galaxies, it turns out, are no less prone to turning a certain shade of red when things get... windy.

Today's paper combines no less than three of my favourite topics : ultra diffuse galaxies, ram pressure stripping, and dark galaxies. UDGs are these large(ish) galaxies which have very few stars, with dark galaxies having no stars at all. The connection between the two, if any, is highly uncertain, and it's possible dark galaxies are actually just clouds of stripped gas and not really galaxies themselves. And RPS is a particular kind of stripping mechanism : the process whereby a galaxy moving through hot, thin gas can build up so much pressure that its own gas can be forced out. In doing so it eventually runs out fuel for star formation, so all the hot, short-lived blue stars quickly die off, leaving behind only the small red ones.

Hence, farting galaxies turn red. Change my mind.

This phenomenon is more-or-less well known in ordinary galaxies, but no-one has yet seen it happening in UDGs. The authors here present a pretty convincing case for the detection of such an event. Just like their bigger, brighter cousins, UDGs suffer the same acute embarrassment when they too are squeezed uncomfortably.

The story actually stars with the detection of a neutral hydrogen (HI) cloud back in 2015. Cannon et al. reported that a few features, this one included, had no obvious optical counterpart. High resolution observations with the VLA revealed that the cloud was suspiciously close to, but not coincident with, a faint optical counterpart. On a quick re-read of Cannon 2015 I'm not quite sure why they thought this was all that odd (displaced gas is a rare but not unknown or unexpected occurrence); interesting yes, strange, not so much.

(Incidentally, I don't like the term "almost dark" that has become popular. There are genuinely dark structures, so I prefer to call these faint but definite systems dim galaxies. But that's by-the-by.)

This current paper reveals a nice connection between the optical object, the HI detection, and some ultra violet extended emission and blobs. The optical galaxy they categorise as satisfying the UDG criteria (which were generally not known about in 2015), albeit marginally. The UV emission (from ionised or excited gas from hot young stars) is slightly displaced from the UDG (by a few kpc, nothing much at all really) roughly on a line from the UDG towards the centre of the Virgo cluster. 

This very neatly fits the "fireball" model of RPS. Galaxies move towards the cluster centre, the ram pressure builds up until stripping begins, and then the tail of stripped gas behind the galaxy can cool and condense and form UV-bright stars. And that's reasonably well-known for larger systems, but never seen before for galaxies like this.

While the UV data gives them information on metallicity (chemical composition), showing clearly that most of the blobs are about what you'd expect from galactic material (and not pristine gas as you'd expect if this were a case of accretion rather than gas loss), their estimated ages are less conclusive. Through a series of really quite tedious modelling, they're able to establish that the peak of RPS most likely occurred around 100 Myr ago or so. They can't see a nice clear age gradient that would really seal the deal on the fireball model, but given the short duration of stripping and the small distance travelled, that's not at all surprising.

There are a lot of very interesting implications from all this. First, they say the galaxy is likely to have been originally a UDG to begin with - not something that formed as a result of cluster processes as some other models indicate. No, they're truly independent systems in their own right, a normal part of the galaxy population and not some cluster-specific thing.

Second, there's a possible connection to the truly "dark galaxies"... well, maybe. At the very least this is a nice example of displaced gas, whereas previously I believe the only other such example in Virgo was M49. 

It'd be extremely satisfying if the totally dark HI clouds could be explained by this, but the third point probably makes this unlikely. The displaced gas still isn't enough to account for how much gas the original galaxy ought to have had (somewhat surprisingly, many UDGs have pretty normal gas contents), so there's been a loss rate of around 4 solar masses per year. That's pretty much exactly the same as seen in much more massive systems. And if this applies to the dark clouds, which don't have much gas left, we're detecting them suspiciously close to the very end of their lives.

(I suppose there could be a selection effect, however. Maybe they only appear as truly isolated clouds just before the last bit of gas evaporates. But this still implies a high production rate of such systems, so this would be an awkward solution at best.)

What's odd about that is that UDGs need to have lower than usual star formation rates, otherwise they'd just be normal galaxies. So, presumably, they have more extended, lower-density gas. It's not in the least surprising that gas removal quenches star formation and make them all embarrassed red, but one might expect the evaporation of lower-density gas to occur at a very different rate to what happens for much denser gas (e.g. it should disperse more quickly and/or change phase to cooler or hotter undetectable gas more readily). But apparently it doesn't. So, is the physics of gas dissolution different, or is there some completely different quenching mechanism at work in UDGs ?

Right now, we've no idea. Interesting as it may be, it'll take a lot more than one farting dwarf to solve all the mysteries of galaxy evolution.

Formation of a red ultra-diffuse galaxy and an almost dark galaxy during a ram-pressure stripping event

We detected a few star-forming blobs in the VESTIGE survey, located at ∼5 kpc from a UDG, namely NGVS 3543, in association with an HI gas cloud AGC 226178, suggesting a recent interaction between this low-surface-brightness system and the surrounding cluster environment. We use a complete set of multi-frequency data including deep optical, UV, and narrow-band Hα imaging and HI data to understand the formation process that gave birth to this peculiar system.

El Fatso The Magnificent

I read this paper out of sheer spite. Being told, "anyone believing in ΛCDM isn't a physicist" at a recent seminar, as well as receiving an unnecessarily insulting comment on an old post, tends to wind me up the wrong way.

Anyway, "El Gordo", which Wikipedia says means "the fat one", here refers to a monster galaxy cluster in the early Universe. It's so massive that it's a bit of a puzzle how such a gargantuan structure managed to form so quickly after the Big Bang. 

But haven't we heard such claims before ? Indeed. The Bullet Cluster is most famous as an example of two colliding clusters clearly demonstrating that the dynamics of the systems does not follow the baryonic matter : i.e., while the X-ray gas clearly gets stuck in the middle during the collision, lensing measurements show that the dark matter doesn't really notice the collision much. But it's only slightly less famous because its sheer mass and the collisional velocity of its sub-clusters were thought to be a problem for ΛCDM, though that prospect receded when it was shown that the collision velocity wasn't as high as initially thought. Even the authors of the current paper appear to concede that point, if reluctantly.

This paper covers quite a bit of ground, so I'm going to strictly limit my comments here as to whether El Fatso does indeed contradict standard cosmology. The MONDian stuff they also present is very interesting, but I think it would have been better as a separate paper (the protracted other arguments against ΛCDM, by contrast, are wearing very thin, and in my view are long since discredited). But, while it's entirely possible that this is a case of boy-who-cried wolf, as it stands I find the evidence that the Fat One is worryingly large considerably more compelling than for the Bullet Cluster.

Essentially, what they do is use an enormous, pure dark matter simulation to search for analogues of El Gordo. This "Jubilee" simulation is the largest to date, covering about the same volume as the entire visible Universe at the distance in question (a fact which is annoyingly buried on page 13). What they try to do is find how often such analogues occur, and given the survey size in which El Gordo was found, estimate if this discovery is compatible with expectations or not. 

Of course, pure dark matter simulations are necessarily limited in what they can tell you. But unlike other cases, where the baryonic physics is almost certainly responsible (in my opinion) for any discrepancy between theory and observation, it's harder to see this being the case for El Gordo. Its two interesting features are its sheer mass and the infall velocity of its two major components. Both of these shouldn't be affected much at all by observations being restricted to the baryonic components. So using a pure dark matter model ought to be perfectly valid in this case.

I do have a slight quibble that their search criteria may be excessively strict : rather than search, say, for objects within some mass/velocity range, they search for objects which are either as extreme or more extreme than El Gordo. That's probably placing a bit too much faith in the observations, but this is largely negated because they show in their figures more detailed distributions of what they found. 

Which is : no clusters at all as massive as this one at any infall velocity. Given the well-defined mass and velocity distribution, they can extrapolate to see exactly how rare El Gordo is (or in other words how large the volume would have to be to contain such a behemoth), and the answer is, "very" : they expect to find of order 0.0000000001 such clusters, so finding even one is very surprising indeed.

Does this mean cosmology is all wrong then ? Possibly yes, though I wouldn't bet on it. I have a lot of issues with the language of the paper - I don't think it makes any sense to use the term "falsify" in the probabilistic sense they do, something that is "false" cannot be false with some given probability value. Likewise they take the 5σ threshold as something magical for some reason, and quote distances and timescales which seem worryingly accurate (e.g. kpc scales when describing something Gpc away; "559 Myr" - I find it very unlikely that such precision is justified). And I'm biased because I'm also continually annoyed that other people continually get away with making extremely grand claims while I get routinely pulled up on things which shouldn't be controversial at all.

But this is all by-the-by. More importantly, the mass dropoff in the simulations is extremely steep : go down a factor three and such clusters do exist in their simulations. So I do wonder just how secure that observational mass estimate really is. Likewise for the infall velocity, which was based on more detailed, smaller simulations. In the seminar they claimed that you couldn't use a much lower velocity and still get the same (quite distinctive) morphology as the observations, but I couldn't really see much difference between the high and low velocity cases in the figures they showed. But I would have to check that more carefully - perhaps I missed something. In any case, however detailed and extensive the previous simulations were, it's always worth remembering that there's more than one way to skin a cat.

What I think has the potential to become very much more interesting is that this monster was found in a relatively small survey. We can argue about probabilities till the cows come home, but for single objects this won't do much good. It is perfectly valid to posit a weird, unlikely occurrence to explain a weird object. Indeed, if the mechanism at work wasn't in some way unusual, we ought to see such oddities everywhere. So however unlikely their simulations say a giant cluster at this distance might be, so long as it is physically possible, a single object is nothing very worrying. After all, it's pretty unlikely that we happen to live on a planet with total solar eclipses, but we don't hold that as evidence against cosmology. You're bound to get some unusual features - flaw of averages, and all that.

But if you can show, as they heavily imply, that they expect such objects to actually be quite common in observations... then you've got something really interesting. Then you're really dealing with physics, not statistics : you need a mechanism that must occur quite frequently. And so far as I know, ΛCDM just doesn't have that.

If I can find the time, I'll try and do a proper paper chase on this one. To be honest, because of certain people's tendency to make exaggerated claims about how obviously ΛCDM is some kind of weirdly dull cult, I view such claims with far more skepticism than I otherwise would. It's hugely counterproductive. And that's a shame, because disproving it would be truly spectacular. I, for one, would quite like to know when their really is a wolf that's come along to gobble up the standard model's carefully-tended fluffy sheep.

A massive blow for ΛCDM - the high redshift, mass, and collision velocity of the interacting galaxy cluster El Gordo contradicts concordance cosmology

Such a fast collision between individually rare massive clusters is unexpected in Lambda cold dark matter (ΛCDM) cosmology at such high z. However, this is required for non-cosmological hydrodynamical simulations of the merger to match its observed properties. Here, we determine the probability of finding a similar object in a ΛCDM context using the Jubilee simulation box with a side length of 6h−1 Gpc.

Maybe massive minis matter mightly

Woohoo, looks like normal paper-reading services have been resumed...

Disclaimer : I work with the lead author on an unrelated project. 

The problem of whether ultra-diffuse galaxies (UDGs) are tiny but massive or just tiny and boring has never really gone away. So far it seems they're all over the shop. Some appear to be such lightweights that lack any dark matter at all, and it's hard to see how they could ever from. Others appear of the opposite extreme, being so massive and dark matter-dominated that they might not fit with standard theories of galaxy evolution. Most seem to be somewhere in the middle, but those extreme values are significant.

The difficulty is that to properly weigh a galaxy's total mass, you need to know how fast it's rotating : there are some clever alternatives, but none are really as good as direct measurements of the kinematics. There are only a handful of cases so far where this has been possible, so every new measurement helps.

This paper presents the atomic neutral hydrogen (HI) measurements for two UDGs in different environments. This is important, since in some scenarios UDGs are formed through environmental processes. The fact that some UDGs (such as one in this paper) are really quite isolated doesn't mean that the majority of UDGS, which are thus far found in clusters, couldn't be the result of some cluster-based process, though it would be a bit contrived and anti-Occam.

The paper is very dense but it's crammed full of science and not excessive details of the observational methods. Their main result is that both galaxies are probably dark matter dominated. Though the resolution isn't exactly exquisite, it's more than enough to see that both objects have ordered rotation.

Of course, there are caveats. The first galaxy has rather messy HI and might have interacted with something. This makes converting its measured velocity width to its true rotation speed more difficult. Their estimates range about 50 - 150 km/s, which means it's either lacking dark matter or highly dominated by it. But the latter estimate, they say, is probably more likely, and its dark matter content in that case (although high) would be consistent with other objects of similar baryonic mass.

The second galaxy is more robust. This is clearly close to edge-on, making the velocity correction smaller and less prone to errors. And this one fits exactly where you'd expect to find a regular dwarf in terms of baryonic and dark mass. But it too has an extension indicating an interaction of some kind - most probably the gobbling up of a smaller satellite, they say. It also has an extremely high ratio of HI to stellar mass. Neither of these features, however, is much of a problem for the kinematic measurements.

So what of those other UDGs that lack dark matter ? Their plot of baryonic mass as a function of dynamical mass is... unclear. If I have to describe it somehow, I'd say there are two distinct populations. One, of normal dwarf galaxies, shows a broad decline in baryonic mass with increasing dark mass. The other, the weirdo UDGs, is a quite distinct cloud. But it's not at all clear - discerning a pattern here is like being given a join-the-dots puzzle without any numbers and trying to work out if it's supposed to be Jesus or a dinosaur. I think the answer is only going to become clear with more and better data. So my only conclusion is that I'm sitting firmly on the fence as to whether these objects are truly strange or just difficult to measure.

Resolved HI in two ultra-diffuse galaxies from contrasting non-cluster environments

We report on the first resolved HI observations of two blue ultra-diffuse galaxies (UDGs)using the Giant Metrewave Radio Telescope (GMRT). These observations add to the sofar limited number of UDGs with resolved HI data. Within the limits of the observations' resolution, our analysis indicates that SdI-2 is dark matter-dominated within its HI radius and this is also likely to be the case for UDG-B1.

Lord Of The Heavy Metal Rings

A two month break from reading papers is getting excessive, so let's address this with a nice little letter about Leo.

The Leo Ring is a gigantic, 200 kpc ring-shaped gas cloud in the Leo group, about 11 Mpc away. With a mass of HI of over 2 billion solar masses, this is one of those weird features that won't go away because someone made a calibration error or something daft like that. The Ring is by and large optically dark, with no obvious bright galaxies that you could point to and say, "yep, the gas probably came out of that one there".

Now some rings are not that complicated to explain : head-on collisions between galaxies can do the job nicely. But ring galaxies are collisional features which tend to be smaller and with more vigorous star formation, and tidal encounters usually have a clearer connection between the stripped galaxy and its lost material. While detecting star formation in a feature this large could be difficult just because it's so spread out, it certainly isn't happening at the level seen in other such collisions objects. It's not that there isn't any at all - UV observations have found some occurring in a few places in the recent past - just that there's not much happening right now.

This letter presents new Hα observations showing that there is ongoing star formation happening in at least a few parts of the Ring (coinciding with the previous UV detections, though I think this is by design). By itself, this isn't terribly interesting. It's not unexpected that parts of this gigantic structure could be collapsing and forming new stars under gravity, thought it's nice to know. What's more surprising is that the metallicity measurements indicate the chemical composition is similar to that of a typical galactic environment, and can't be explained by the enrichment due to the observed star formation.

The strange thing about that is that previous observations (from absorption lines in background quasars) showed that metallicity was very much lower. That would point to a primordial origin of the Ring, with the material condensing out of low-density material in the general field. I'm always skeptical of such claims of accretion : my question is always, "why are we seeing this happening here and not everywhere else ?". So an origin by some stripping mechanism, though it would have other problems, would at least knock this one on the head.

How come the previous estimates were so much lower ? They say it's because it relies on estimating the density of the HI material in the Ring from low-resolution observations, which underestimates the true density. So higher resolution observations could help with this.

Disclaimer : Leo is of particular interest to me because we have AGES data there. Unfortunately it isn't of any higher resolution than the existing observations, just of higher sensitivity. It doesn't reveal any smoking gun, but it's still interesting. Watch this space.

Heavy elements unveil the non primordial origin of the giant HI ring in Leo

Taking advantage of MUSE (Multi Unit Spectroscopic Explorer) operating at the VLT, we performed optical integral field spectroscopy of 3 HI clumps in the Leo ring where ultraviolet continuum emission has been found. We detected, for the first time, ionized hydrogen in the ring and identify 4 nebular regions powered by massive stars.

Windows Subsystem For Astronomers

It's been dead around here of late because I just can't work up the energy to read a paper. Soon, perhaps.

Today, I want to do something a bit different : extol the virtues of Windows Subsystem for Linux. You can hate me all you want, but I will defend to the death (a) the Star Wars prequels and (b) Microsoft Windows. I cannot for the life of me understand people who prefer Linux, let alone people who - urrgh ! - prefer command line "interfaces" to GUIs. These people are why we cannot have nice things. The main purpose of Linux, in my view, is to break your computer and make the problems absolutely incomprehensible so you have no idea what the hell just happened.

But I digress. Anyway, what is WSL and why should you, an astronomer, care ?

WSL is a way of running Linux under Windows almost like any other Windows program. You get a full Linux installation which you can open from a terminal on your Windows desktop. And although the support isn't native, it's entirely possible to get Linux GUIs to run as well. And run properly, in a useful, no messing about way. In short, WSL is ideal for people like me : those who prefer using Windows but need Linux for work.

Of course, there are alternatives. The classic is to dual boot your machine. I managed this once, but my Linux installation was forever unstable and would randomly freeze, making it unusable for any real work. And it's not a terribly convenient solution having to restart your PC every time you want to switch operating systems.

Another option is to create a virtual machine to run Linux from Windows. I haven't tried this, but as far as I can determine the main drawback of this is a performance penalty, and integrating the two systems is difficult.

My experience of WSL has been nothing but positive. It's easy to install (though not as easy as installing a regular Windows program), integrates seamlessly with Windows, and suffers no loss of performance (when I tested it, I actually found my Python code was running slightly faster under WSL than Windows !*). You can have apps running directly on the Windows desktop or inside a window showing a full Linux desktop. Basically it does all the things. Well, very nearly all, as we'll see.

* Okay, fine. You can take that as evidence of Windows as a crappy operating system if you really want to. Happy now ?

By way of a demonstration, then, let me walk you through exactly what I've been able to get WSL to do - and how.

Installation : 1 - The Basics

Although not quite as straightforward as downloading a regular .exe file and running it, I found this process to be simple enough. There's nothing more involved than copy and pasting some commands into a standard Windows command prompt. Specifically, mirroring the official instructions found here, let me go through this step by step.

First, you may as well check if you have a compatible system, so run :

• systeminfo | find "System Type

This will tell you if you have an x64 or ARM64 system. I haven't a clue what this is, but apparently you need to know this for the next step :

• ver

This is simply to check you're running a compatible version of Windows : for x64 systems : version 1903 or higher, with build 18362 or higher; for ARM64 systems : version 2004 or higher, with build 19041 or higher. If it looks good you can get on with things. So now enable WSL as a feature by running : 

• dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

Next, enable the built-in virtual machine feature of Windows :

• dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Now you need to download the core Linux package. If you have x64, use this link. If you have ARM64, use this one instead. Run these like any other Windows program, enabling permissions as necessary.

Next, enable WSL version 2 as your default :

• wsl --set-default-version 2

Finally, download the particular version of Linux you want to use from the Windows Store. This is as easy as installing any other Windows program : click the version and then "get". It'll then take a minute or so to set everything up, and you have to create a new user account for Linux. 

I'm using Debian, because this is the one I'm familiar with. You'll get a little Debian icon you can click on to open a Debian terminal, or you can use the new "Open Linux shell here" option added to the Windows shift+right-click menu (taking you inside Linux directly to the folder from where you clicked). Or, if that's not enough, you can run "wsl" or "debian" from a Windows command prompt or PowerShell to start it that way. While WSL gives itself some dedicated Linux space (all the usual /usr/local etc. directory structures are there), you can access all your regular Windows folder through /mnt/c (or whatever drive letter you use). Just cd into this like a normal directory to access everything. 

Although this process is a bit more elaborate than the usual download->run program approach, it's very forgiving. I made an unrelated error later on than broke my Debian installation, so I just re-ran the whole process and everything worked once again. What's more, this didn't uninstall the Linux programs I'd already set up.

Installation : 2 - GUIs

Congratulations, you now have a fully-functioning Linux installation running under Windows. But to my mind this is absolutely useless unless you're manically obsessed with text adventure games. Come on, any serious work requires a graphical interface, for goodness sake. This isn't 1992.

Getting GUIs to run took a little more digging since this isn't supported natively for some reason, at least not yet. It's a bit more work than getting WSL itself to work, but in the end it's not too difficult. Look, I hate this kind of computing-wizardry crap, and even I managed it. If I can do it, and you're the sort of person reading this blog, then you can do it too.

Essentially what you have to do is use a X-server, just as if you were remotely logging in to a computer on another network. Except this time you're logging in to your own computer, which is a bit weird but it works (and is very much faster than remote logging, which is normally better through VNC).

Normally I use XMing for this stuff. However, on encountering some complications in the process, I decided to follow the various guides step-by-step to ensure I was doing everything 100% correctly. So here I'm using VcXrv. I'm sure it's possible to use XMing instead, with the right settings, but this worked for me.

Running Linux programs on the Windows desktop

Run an X-server

Install VcXrv on Windows like any other program. Let's start with assuming that you'll want to run Linux programs on the Windows desktop - we'll get to running a full Linux desktop later on as that's a bit harder. So run VcXrv and on the first screen set it to use multiple windows. Leave the options on the second screen unchanged. In the third start-up screen, enable the option "disable access control" (I believe that adding a switch "-ac" to the shortcut does this as well). You can then save yourself some considerable hassle by saving the configuration files from the fourth and final start-up screen. This is much more useful than saving you from having to set all the options each time, and we'll see why a bit later on.

If you're very lucky, running the X-server will already be enough : with the X-server running, try launching the built-in "xeyes" program in WSL to test it. If it works, it'll launch instantly. If not, you may get some error message, or it may just do nothing except make the Linux prompt unavailable until you hit ctrl+c to cancel. If that happens, the next two steps should solve this.

Configure Linux to accept the X-server

It took a lot of Google searching but I finally figured out that there were two independent problems impairing my access to Linuxy goodness. First, I had to configure Linux so that it would interface with the X-server correctly. Apparently this is done by running the command (in a WSL prompt) :

• export DISPLAY=XXX.XX.XXX.XX:0; where the correct address can be found in the file /etc/resolv.conf. This is a tiny file so you can read it with the built-in "more" command easily enough.

Try running xeyes again, it might already work. But even if it does, there's a complication here : that address changes. It was horribly annoying to have to adjust this every time I started Linux, but fortunately there's a workaround for that. Before that though, I had to solve the second problem. Despite trying numerous solutions (mostly infinite variations on the export DISPLAY command), I still couldn't get GUIs working. Eventually I found that the problem was - of all things - the firewall. Of course, if you've got the app working already, you can skip the next step.

Tell the Windows firewall that everything's okay

It seems bizarre that you need to alter firewall settings to get GUIs to open from programs running locally, but extensive searching and testing proved to me that yep, this is exactly what you need to do. As soon as I disabled my firewall (it only takes a few seconds to test the xeyes program, so the risk is probably minimal) I could launch Linux GUIs no problem. Of course, disabling the firewall to run Linux is Seriously Bloody Stupid, maybe even Darwin Award Stupid, for ordinary use, but all you really need to do is enable a port. I'm using McAfee, and I had to do the following :

• In McAfee go to "PC Security", "Firewall", "Ports and System Services" and then add a new one. The name and description etc. are just convenient labels in case you need to refer back to them in the future. The important thing is to enter "6000" in the "Local TCP/IP Ports" section and make sure "Forward port activity" is ENABLED.

That's it. There should be no need to restart the PC, though you'll probably need to close the X-server and Linux (if they're still running) and reload them. So do that, try xeyes again, and with any luck it should now work perfectly.

Adjust your Linux .bashrc file so we never need to do any of this ungodly horror again

This is nice, but still leaves us with the need to open an X-server and find the address we need for the export DISPLAY command every time we start Linux. This is... unpleasant. Fortunately, there's a way to automatically generate the full command :

• export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0

Isn't just Linux just lovely and so marvellously intuitive ? Hell, no of course not. But we need never bother with this ugly thing in practise - or with manually starting the X-server either. In fact one of the really neat tricks about WSL is that we can start Windows programs from within Linux. So all we need to do is set up an alias that can configure Linux and launch the X-server in Windows all at once. That's where saving the X-server configuration file comes in handy. In Linux, I edited my .bashrc file to include the following :

• export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0
• echo "For GUI functionality either run 'xapps' (apps only) or 'xdesktop' (full LXDE desktop)"
• alias xapps="'/mnt/c/Program Files/VcXsrv/xlaunch.exe' -run 'C:My\Directory\AppsOnly.xlaunch'"

EDIT : On Ubuntu, it may be necessary to slightly alter the last command :

• alias xapps="'/mnt/c/Program Files/VcXsrv/xlaunch.exe' -run 'C:My\Directory\AppsOnly.xlaunch' &> /dev/null &"

Without this "&> /dev/null &" on the end, the .bashrc file may (for some silly reason) not process the alias correctly, so it will run with no errors but not actually do anything. This modified command causes no problems on Debian, so if in doubt use this version.

The first step is exactly as before, to configure the Linux display for the X-server. The third generates a command "xapps". Typing this in my Linux console automatically runs the X-server using the configuration file I saved earlier (Note : if you move this file, the command will break and you'll have to edit the new path in the .bashrc file. This is worth remembering ! I did this once and completely forgot about all this setup, so for quite a while I was dumbfounded as to why it had suddenly stopped working). The second line just prints a helpful reminder to myself, every time I start a new Linux session, about how to run this very important command.

Running a full Linux desktop under Windows

You may have noticed that my reminder statement in the last step includes a command to launch a full Linux desktop. If you don't want this, if you're happy enough with Linux programs by themselves, you don't need to bother with the alias. Just include the launching command in the .bashrc file to have the whole thing run automatically on starting Linux.

But if you do want a full desktop as well, you'll need a separate X-server configuration file. The only difference is that this one should use "one big window" (or probably better "fullscreen") instead of multiple windows. You may as well create that now. I think you also need to set the display number to zero. You'll also want to add one other line to your .basrhc file. After the export DISPLAY command :

• export LIBGL_ALWAYS_INDIRECT=1

Unfortunately there's more to this than just altering the X-server. Since GUIs aren't officially supported in WSL yet, it doesn't come with a desktop facility - you'll have to install this yourself.

To do this, it's worth running some commands on Linux to ensure it can find all the latest, correct packages :

• sudo apt update
• sudo apt upgrade
• sudo apt-get update -y

Which might take a few minutes. You can then go and get yourself a desktop. For this I used LXDE. This is easily installed on Linux :

• sudo apt-get install lxde

And then you run it with "startlxde". With your X-server running, you should get a shiny Linux desktop in one big Windows window. It's a little finicky about whether the "one big window" mode really means full screen or hides the taskbar because the window extends beyond the edge of the screen, but it should basically work (fullscreen mode seems more robust to me; clicking on the main window header bar also helps). What you don't want to do is have the two different X-servers running simultaneously. You can either have Linux programs or a Linux desktop, not both, at least not that I've been able to figure out.

And then set yourself a second alias, much like before :

• alias xdesktop="'/mnt/c/Program Files/VcXsrv/xlaunch.exe' -run 'C:\My\Directory\FullDesktop.xlaunch' && startlxde"

That's pretty much it for WSL. It's some work to set up, but when it's done, it's triviality itself. Each time I open a Linux terminal I see the commands to run the GUIs so I never forget, and all I have to do is type them and I'm basically using full Linux under Windows. The actual number of commands you need to do to get everything to work is small - it was figuring out what those should be that's the time consuming bit. Hopefully, with this guide, that should now be ~30 minutes work or less.

What I cannot remember is if I had to configure the GUI in the Linux desktop or not, i.e. because I have a very particular preference for the workspace manager. Also, on startup I get an apparently useless error message about "No session of PID 384", which some Google searching has demonstrated is more difficult to remove than it's worth, so I haven't. 

Finally, I haven't fully figured out how to have the full right-click option on the Linux desktop. The best I've found is :

• Preferences -> Desktop Preferences -> Advanced -> DISABLE "show menus provided by window manager when desktop is clicked"

Which gives me something, though it's limited : I can open a terminal on a selected folder but not just in the current directory. Weird, but despite the limitation this level of functionality is more than sufficient to use it in anger.

EDIT : This all works fine for me on Debian, but Ubuntu may have problems using the .bashrc file. A short guide to fixing this is here.

Astronomy in WSL (these instructions should also work for standard Linux)

There are three tools I just can't do without : miriad, ds9, and kvis. Miriad I use for spectral analysis of HI data cubes (being from an earlier era, it's outstanding at handling even files which are tens of gigabytes in size). Ds9 is a FITS viewer that's trivial to install on Windows, but its "funtools" plugin for optical photometry is more difficult. Kvis is part of the karma package* and is an excellent, lightweight FITS viewer explicitly designed for 3D cubes. I also sometimes use IRAF, Gaia, GILDAS, and various others, but very much less frequently than the big three.

* Not the ESO one.

You might well wonder why I use other FITS viewers given that I've been developing my own since 2012. Two reasons. First, kvis is fast, ultra-well-tested, and is good for making publication-quality plots. It's not exactly feature-rich (in fact, for analysis it's downright dismal), but it more than makes up for that in speed, reliability, and like miriad it's great at handling very large data sets (though not at the tens of gigabytes level). Ds9 for me is all about the aperture photometry, which is just amazingly simple to use. 

Second, while I rely heavily on FRELLED/Blender, this is the only program I've so far been unable to run in WSL. As far as I can gather this is a fundamental limitation of WSL's handling of OpenGL, which I expect will be fixed in due course. But even then I'll still be using kvis : for pure visual inspection, so long as nothing particular complex is required, it beats everything else hands down. It's a great shame development was abandoned.

For now, having access to these tools is such a godsend that I'm still getting used to it. I don't have to put up with Linux's crap any more, I can just get on with stuff in nice, friendly Windows. So let's go through the installation of ds9/funtools, miriad, and karma. Most of the other basic Linux apps tend to be no more complex than the standard sudo apt-get install, so I won't cover them. These more specialist apps require certain compilers and libraries, so it's useful to document these steps that everyone does once, instantly forgets about, and then struggles to remember what the hell they did the next time they try installing stuff.

DS9 with funtools

The main ds9 program is just a simple binary file : download it and create an alias in your .bashrc file to run it however you like. The "funtools" (FITS Users Need Tools) plugin is a bit more involved. There's a "funtools.ds9" file, but I'm not sure this does anything by itself. Unfortunately you have to compile funtools from source. Following these instructions, here's what I did.

First create configuration files :

• sudo ./mkconfigure

These gave me an error "autoconf not installed" but this was easily fixed with :

• sudo apt-get install autoconf

I re-ran the mkconfigure command, which now worked. So then I tried to set the configuration to use a target installation directory :

• sudo ./configure --prefix=[installdir]

I think for [installdir] I used. /usr/local/ds9/funtools. But this gave an error, "configure: error: no acceptable C compiler found in $PATH". This was fixed with :

• sudo apt-get install build-essential

After re-running the configure command, all I had to do was :

• sudo make
• sudo make install

And that's it : funtools was automatically added to the ds9 Analysis menu, with no need to use the .ds9 file at all.

Well... not quite true. Funtools is actually using a different funtools.ds9 file than was compiled. This means it gets a bit finicky about where the "funtools-master" directory is located. I put it in ~/ProgramFiles (it wasn't happy if I put it somewhere more sensible like /usr/local/ds9/funtools). Then in ds9 itself, I set Edit->Preferences->Analysis to have this file autoload on startup. Et voila, aperture photometry on "Windows" :

Karma / kvis

The main problem with installing karma is not that it's difficult, it's that it's sufficiently obscure that finding installation instructions that actually work is a bugger. The main result keeps coming up with this page, which describes how you can use a single rsync command and everything will be as lovely as riding a magical unicorn. Unfortunately this seems to be out of date, since the files are no longer hosted where they're supposed to be. The unicorn has gone missing.

Eventually, I found these instructions which do actually work, which I'll mirror here. It's actually pretty simple, since karma is basically a series of pre-compiled binaries. Basically you download a couple of packages and make some minor adjustments to the .bashrc file.

First you'll need some command-line way to access the files via url. I use wget :

• sudo apt-get install wget

Then created a directory "karmafiles" where I could download and unpack everything (this is just a temporary holding area, the real installation directory comes later). From there :

• wget ftp://ftp.atnf.csiro.au/pub/software/karma/karma-1.7.25-common.tar.bz2
• wget ftp://ftp.atnf.csiro.au/pub/software/karma/karma-1.7.25-amd64_Linux_libc6.3.tar.bz2

Those directories also contain manuals, though those are optional. The main files need to be unpacked into the temporary directory :

• tar -xvf karma-1.7.25-amd64_Linux_libc6.3.tar.bz2
• tar -xvf karma-1.7.25-common.tar.bz2

But Linux complained that bzip2 was not found, though this was easily fixed with :

• sudo apt-get install bzip2 

Now the tar commands should work. They unpack the files to a single common directory "karma-1.7.25" (how they do this I know not, but they do). I moved this to /usr/local/karma : 

• sudo mv karma-1.7.25 /usr/local/karma/

Finally there are a few lines to add to  ~/.bashrc :

• LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/karma/amd64_Linux_libc6.3/lib/
• export LD_LIBRARY_PATH
• export KARMABASE=”/usr/local/karma/amd64_Linux_libc6.3″
• alias kvis="/usr/local/karma/amd64_Linux_libc6.3/bin/./kvis"
• alias kshell="/usr/local/karma/amd64_Linux_libc6.3/bin/./kshell"
• alias kpvslice="/usr/local/karma/amd64_Linux_libc6.3/bin/./kpvslice"

I just put them all at the end, with a comment to indicate that this was stuff for karma.

And that's it. Kvis runs just fine. It even supports its feature of moving the pointer via the cursor keys and freezing the coordinates with the space bar, so long as NumLock is off. It sometimes has a display issue with some of the buttons not showing up correctly, but I think this only happens when I forget to close an old X-server.

Miriad

This is basically the same as for karma. The main installation guide is here, and again I'll mirror those instructions for the sake of my own convenience.

First download the two packages, one common and one OS-specific :

• wget ftp://ftp.atnf.csiro.au/pub/software/miriad/miriad-common.tar.bz2
• wget ftp://ftp.atnf.csiro.au/pub/software/miriad/miriad-linux64.tar.bz2

Unpack them into a holding directory (I called this "miriadfiles") :

• tar -xvf miriad-common.tar.bz2
• tar -xvf miriad-linux64.tar.bz2

Move the common directory this creates to its proper installation location, /usr/local/miriad : 

• sudo mv miriad /usr/local/miriad/

Then we do some procedure to replace the directory in the miriad initialisation file :

• MIR=/usr/local/miriad; export MIR
• cd $MIR
• sed -e "s,@MIRROOT@,$MIR," scripts/MIRRC.in > MIRRC
• sed -e "s,@MIRROOT@,$MIR," scripts/MIRRC.sh.in > MIRRC.sh
• chmod 644 MIRRC*

Apparently this changes the path in the file $MIR/scripts/MIRRC.in from the default "@MIRROOT@" to the correct path, e.g. /usr/local/miriad, and saves the result in the file MIRRC (similar for MIRRC.sh.in). I presume you could also do this manually if you wanted to.

Finally we make some additions to the .bashrc file so we can start miriad anywhere, which is a bit different to simply setting an alias :

• source /usr/local/miriad/MIRRC.sh
• export PATH=/usr/local/miriad/linux/bin:$PATH
• export PATH=$MIRARCHD/bin:$PATH

And that's it ! It just works.

The only - very minor - downside is that we cannot simply run miriad by doing "wsl miriad" from Windows, even though other Linux commands are supposed to work like this. This is likely a minor limitation of WSL for now. Apart from that, miriad appears to be fully-functional. No need to muck about with the notoriously awful PGPLOT library or anything daft like that.

So that's it. Today I managed to (a) insult Linux fans and (b) finally document those annoying installation procedures I've been meaning to document for bloody years. Time to celebrate with a nice cup of tea.

Data visualisation : the next level

This is going to be a very strange post in which I describe pretty pictures but don't actually show you what I'm looking at. Why ? Because I'm using a VR headset, and I can't yet make the final media into a shareable format.

I now have a computer capable of VR. This is almost as big a jump as getting the standalone Quest headset itself, because the graphical capabilities of the PC far exceed the high-end smartphone level of the headset alone. 

One of the first things I tried was to examine the tiny handful of models I've uploaded to Sketchfab. On the Quest by itself, these are barely functional. The framerate and/or tracking are lousy, and though you can get the general idea, the experience is unpleasant. Not so with the PC, which easily handles much more complex models than these. So I can walk around my model as though it was actually there in my living room. I can even interactively rescale it with the thumbsticks. But of course, using Sketchfab isn't very convenient, especially given the pathetic limitations imposed on uploads.

That's where FRELLED comes in*. I used Blender 2.79 for this, partly out of ignorance. When I first looked at Eevee, back during the early test builds for 2.80, it wasn't up to much. Textures loaded slowly and even simple tests of FRELLED weren't at all successful, with the view essentially re-rendering whenever anything changed at all. That completely breaks the main benefit of FRELLED, which is that the view should update instantaneously (that is, at > 25 fps) and in real time. Since Blender 2.8+ lacks any other realtime capability, I stuck with 2.79.

* I've now managed to confirm that this works both on Windows and Mac. There's still quite a bit to do, but it's getting closer and closer to being released into the wild.

But nowadays Eevee is massively more powerful. For scenes as simple as those FRELLED constructs, Eevee renders in true real time, not the pseudo-realtime of before. And it doesn't have the problem of transparent materials needing to be ordered correctly, and - maybe best of all - you can adjust the brightness and contrast of materials in realtime as well. That makes it a dramatic and wholesale improvement over Blender 2.79's capabilities, not a poor substitute with a few fringe benefits.

Unfortunately, the switch from the Python in Blender 2.78 to 2.8+ is significant enough that I can't just directly convert everything. So FRELLED version 5 is already looking obsolete compared to a planned version 6, though, mercifully, the conversion will be nowhere near what I've had to do in the upgrade from Blender 2.49 (essentially a complete re-write of all 11,000 lines of code). But there's one capability of Eevee which I simply had to try out : virtual reality.

Getting this to work was remarkably easy. I started with importing isosurfaces and adding a few lights. Then I plugged in the headset, enabled the Link, and hit "start VR server" in Blender. And it just worked. I had a greyscale surface of M33 floating in front of me that I could walk around. Or at least partway, due to the limited length of the cable (I've got the wireless version of Virtual Desktop running, but so far that only works with Steam and I haven't figured out how to run it with Oculus software yet).

From there it was a simple matter of playing with Eevee's materials to get something more shiny. For my purposes, I barely need any lights - I can do everything with the material preview. In an hour or so I had this, floating in front of me. I could even stick my head inside it, though Blender gets sluggish if I do :

Now of course that needs some more effort to come up with nicer materials, but the proof of concept is solid. I was so impressed by how well this worked I began to wonder if it might even be possible to do the full volumetric display of FRELLED. And soon I found that yes, yes it is. I wrote a couple of short Python scripts to automate most of the process. So now I get to see M33 in its full volumetric glory, rendered as a cube about half a metre across that I can walk right round.

The main limitation appears to be proximity. From around 0.5m away the frame rate is very good. Get much closer, though, and it drops sharply. You can stick your head inside, but it's not much fun. I'm not sure why this is but I guess it's a limitation of Blender. Still, even this is more than sufficient for outreach.

And in some ways this is even simpler than the old process. Blender 2.79 had problems ordering materials, so that transparent surfaces weren't rendered correctly from behind. This meant an elaborate series of forward and reverse images with a background script deciding which ones to show based on the viewing angle. This isn't necessary in 2.91, where I can just show everything at once. I might eventually use a simpler version of the script to deal with larger data sets, but for small ones it isn't needed at all.

Is there any practical, scientific benefit to this though ? Honestly, I dunno. Personally I think the more visualisation techniques we have access to, the better. When you actually see it, I don't think there's any question that this is inherently better. The greater immersion helps focus on features you might never have noticed (but I won't really know this until it's developed enough to use in anger). Granted, VR could still benefit from lighter, cheaper headsets at higher resolution, but this was once true of television as well. If there's one piece of tech that's come closest to the sci-fi predictions of the last few decades, then VR is surely a leading contender.

Of course, at this stage it's nice for outreach but useless for science. Still, the current technology appears adequate to the point that it's the software which is now the chief bottleneck. Greater native integration of VR hardware in Blender would be nice, though I'd prefer some format which could be easily shared online without having to give away the actual .blend file*. But it's entirely feasible to conceive of sticking on a headset and doing all the standard analysis in VR, with negligible additional effort compared to using an ordinary monitor. In fact it's already possible, in that this could be developed on a timescale of weeks or months - certainly not years.

The only major practical issue, though, may not be the hardware so much as the space requirement. We're not going to be giving up 2D screens any time soon. Whether anyone will feel that the capabilities of VR are so beneficial as to give it dedicated areas (at least in astronomy) is something we're just going to have to find out by experiment. Personally I think it's something well worth exploring.

The little gas cloud that could

Back in the halcyon days of March 2018 there was a very interesting paper about the discovery of an isolated gas cloud in Virgo. We know of a few of these, of course, and they're all interesting and most are hard to explain. What's remarkable about this one was that while it's quite isolated, it has (apparently) an entirely young stellar population. 

Now, gas clouds that don't do anything are weird enough : what stops star formation in some objects but not in others ? This cloud makes things even worse. Accepting that there is indeed some star formation family planning mechanism at work, we now have to understand why this spontaneously fails. Why did this cloud wander around in the void before, for no apparent reason at all, it just decided to go THWOOP and start forming stars all of a sudden ?

At least the survival of the cloud seems a bit clearer, with the previous paper showing that this could be a result of pressure confinement by the intracluster gas. My own work has shown that this basically doesn't work for clouds with strong enough internal motions, but this little cloud (dubbed SECCO 1) has much more well-behaved gas. So it could indeed move quite slowly through the cluster (it's in a region where the velocity dispersion of the galaxies is a lot lower than the average) and survive for a billion years without being torn apart.

This new paper builds on that with a series of new, more advanced, 3D simulations. Again they examine the behaviour of such a cloud after its formation, and don't look at the formation process itself (which would be complicated and require a very different setup). They confirm the previous findings, and to be honest, a large chunk of the paper is given over to extremely laborious descriptions of what the simulations show. They can be summarised thus : the cloud gets disrupted but survives. It gets very slightly more or less disrupted depending on the exact choice of parameters. To be honest, at times it gets downright tedious.

But it's worth slogging through this one, as there are at least four interesting results here. First, they can't explain the sudden onset of star formation, which personally I think they should make a much bigger deal out of : this cloud is weird. It naturally lends itself to clickbait : "This gas cloud just started forming stars and no-one knows why", "Watch as this gas cloud moves through the Virgo cluster - you won't believe what happens next !" and so on. 

To be fair, modelling the cause of the onset of star formation isn't really their goal. Instead they try to model the overall star formation history, and that raises the second interesting result : they just can't get this right. If they have the correct current star formation rate then the stellar mass is much greater than the real cloud, whereas if they have the correct stellar content then they underestimate the current star formation activity. This seems to be closely related to the first point though, as in their model star formation begins immediately, whereas in reality it seems to have started only very recently. More observations could help reveal if there is a faint, old population hiding here. And the lack of modelling the formation scenario is perfectly understandable, but means we're missing all the corner pieces of the puzzle. And the edges. And quite a lot of the inside ones too.

The third interesting result is that motion through the intracluster gas actually helps the cloud survive. It's not just the static, thermal pressure keeping the cloud from flying apart, but also the dynamic ram pressure. Rather than creating a big horrible mess, what this does is increase the cloud's density so that it can cool faster, becoming even denser and thus be less vulnerable to ram pressure stripping. I wouldn't have expected that.

The fourth result is that the cloud may point towards a lack of a clear threshold for the onset of star formation. Observations traditionally indicate a distinct break in the relationship between gas density and star formation rate, although when volumetric effects are taken into account this might disappear. The average density of the cloud in their simulations is substantially below this value, and although the density might be higher on the very smallest of scales, it's at least a valid challenge to the idea of a threshold. Still, since they don't get the star formation history right, this one needs to be treated with a bit of caution. In any case, the cloud is more than strange enough to deserve more attention.

Hydrodynamic simulations of an isolated star-forming gas cloud in the Virgo cluster

We present a suite of three-dimensional, high-resolution hydrodynamic simulations that follow the evolution of a massive (10^7 M_sun) pressure confined, star-forming neutral gas cloud moving through a hot intra-cluster medium (ICM).

Filamentary faff

I've been slacking on reading papers lately, but as I download 560 GB of data from my old Arecibo account (in the unlikely but possible event that the telescope collapse could result in data loss), I managed to read this one about galaxy filaments.

Filaments are rather under-appreciated things. Clusters, being very dense and full of galaxies doing all kinds of interesting things, tend to get all the glory. And it's not entirely unfair : with lots of galaxies all at a fixed distance, and all kinds of crazy environmental effects at work, clusters are both interesting and observationally advantageous places to study. But it's in filaments, the largest structures in the Universe, where most galaxies actually live. Clusters are interesting but they're also weird, and not typical of how galaxy evolution proceeds in general.

Arguably filaments aren't real. They aren't gravitationally bound, so in some sense they're transitory. But this rather misses the point : galaxies (it's generally thought) grow mainly via mergers, so they too could be deemed to be transient; being gravitationally bound today is no guarantee that will be true tomorrow. The key feature is that the processes at work to form a filament could very well influence the evolution of galaxies within them, and this evolution outside of galaxy clusters is usually described with the catch-all term preprocessing. The extent to which this happens is controversial and poorly understood.

This paper looks at preprocessing by studying the major properties of galaxies in seven different filaments. It does this is the classic way of seeing how the galaxies properties vary with distance from the spine (what they call the vertical distance for some reason, and never properly define). The trouble is that the authors don't do this very well.

For starters the sample size isn't clearly defined. They distinguish between galaxies which are in groups and which aren't, but it isn't clear how many are in each. The number of 289 is bandied around but I honestly don't know if this refers to group members or non-members, and whichever it is, I don't know how many are in the other. It's a bit odd that the value of such an important parameter isn't made a lot more obvious. Likewise, the filaments on their sky plot look extremely narrow, and it's a shame they didn't try something three-dimensional, which would really help in showing how good their filamentary membership criteria really are.

The first thing they try is to plot how galaxy density varies with distance from the spine of each filament. In general this decreases and then levels off as the population merges into the general field. But there's one clear exception to this, which shows a decrease to the edge of the filament and then a sharp rise before levelling off. Nowhere do they comment on this.

Then they look at the parameters of the galaxies themselves, but the results are similarly uninformative. Most galaxies in their sample are dwarves, but this is true in general so doesn't tell us anything. There's a very, very weak trend (0.05 magnitudes) in galaxies becoming bluer (indicating more star formation) and less massive with greater "vertical" distance, but I wouldn't call this at all convincing : for comparison, the colour difference between a typical blue and red galaxy is more like 0.5 magnitudes. 

More interesting would be to check how colours vary in a fixed mass range. They do try this, but only divide their sample into two huge mass bins, so this doesn't really show anything. They also plot how the mass varies as a function of vertical distance within the mass bins, which I found distinctly odd. You can't use mass as the control parameter when you're dividing your sample by mass - that just doesn't make much sense. Why would there be a trend in mass within a given mass range ? A trend in diameter, now that might be more interesting.

A similar confusion afflicts their plot of how the gas fraction varies. For this they simply take the mass ratio of gas to stars. The problem is that this (innately) varies strongly as a function of galaxy mass, so by itself this doesn't tell you anything : you have to control for total mass as well. Deficiency is a much better parameter to use, but the intrinsic scatter is very large so any trends will still be hard to see even with a very large sample.

All in all, I don't think this paper has any useful conclusions at all. Certainly filaments could have important levels of preprocessing (at least some of them probably do), but this analysis doesn't tell us whether they do or not. They need a much more detailed analysis and probably a very much larger sample size. Just because a trend is weak or unclear doesn't make it any less real or important, but it does make it a lot harder to verify.

Properties of Galaxies in Cosmic Filaments around the Virgo Cluster

We present the properties of galaxies in filaments around the Virgo cluster with respect to their vertical distance from the filament spine using the NASA-Sloan Atlas catalog. The filaments are mainly composed of low-mass, blue dwarf galaxies. We observe that the g - r color of galaxies becomes blue and stellar mass decreases with increasing vertical filament distance.