Review of GWO Case Study

[rossbar]

A few comments on the LIGO/GWO case study (related to review of EHT case study in #175)

Again, my overall take from a quick readthrough is very positive - it's a very interesting article that, in my opinion, does a great job highlighting a really compelling example!

Some thoughts on a few things that stood out to me:

• The image at the top is very nice, but I would also cast a vote for including an image of the "chirp" from GW150914. This image is nice for several reasons: it is more closely tied to the data & analysis (which is where NumPy is most relevant) and the visualizations themselves were made with matplotlib and/or MPLD3, which is a nice acknowledgement of the scientific Python ecosystem.

• Gravitational waves are ripples in the fabric of space and time

  In such instances it should be "spacetime", one word - this refers to a specific model used in physics

• collision and merging of two black holes or coalescing binary stars or supernovae

  A useful term here is compact binaries (i.e. the cb from pycbc). This covers objects with enough mass to produce detectable (with current sensitivity) gravitational waves during merger events, like neutron stars and black holes. In particular, there are two GW events it might be good to focus on that correspond to the two "biggest" (or at least most well-known) GW observations from LIGO/Virgo: the original discovery of gravitational waves, GW150914 (from a binary black hole merger) and the first direct detection of neutron start mergers, GW170817

• The new LIGO discovery is the first observation of gravitational waves themselves, made by measuring the tiny disturbances the waves make to space and time as they pass through the earth

Note that LIGO has made quite a few interesting observations during the first couple measurement campaigns - I would re-word this sentence to focus specifically on GW150914, which was significant in being the first observation both confirming the existence of gravitational waves, and the ability to directly measure them.

• It has opened up new astrophysical frontiers that explore the warped side of the universe—objects and phenomena that are made from warped spacetime.

I'm not sure about the phrasing of "objects and phenomena that are made from warped spacetime". One alternative would be to re-word this sentence to emphasize that GWO allow scientists to observe and study the universe in a brand new way, ushering in the era of gravitational wave astronomy

• General comment re: the discussion of computational challenges - there seems to be some conflation of various different computational challenges involved in detecting and analyzing valid gravitational wave signals. You mention quite a few of the very interesting computational tasks that go into the analysis, though the relationship between them could be made more clear. For example:

  Gravitational waves emitted from the merger cannot be computed using any technique except brute force numerical relativity using supercomputers.

  I think the individual components could be more clearly separated: the simulation component to generate template models for the "brute force" search of the parameter space. Also, I don't know what role NumPy specifically played in the relativistic simulations. This comment also pertains to the summary/graphic at the end - the connection between NumPy (and other tools in the scientific Python ecosystem) and the GWO analysis pipelines could be made more clear and explicit.

• The amount of data LIGO collects is as incomprehensibly large as gravitational wave signals are small.

  I would recommend staying away from statements like this about data scale - in this case, the technological challenge of achieving sensitivity to gravitational waves is way harder than dealing with the scale of the data coming from the instruments.

• Re: how NumPy was used in the analysis, I would focus specifically on pycbc and GWpy, which you mention in the final bullet point. There is a much more concrete relationship between how these libraries rely on NumPy than the bullet points further up, which list more generic computational tasks that don't necessarily highlight specifically how NumPy contributes. For example, in pycbc, the time series data are stored in ndarrays and scipy.signal, which operates on NumPy arrays, provides the filtering and other signal processing tools used in the analysis of the "chirp" signal.

Also - a dependency map for pycbc and/or gwpy like the one for eht-imaging would be a nice addition!

[shaloo]

@rossbar , thank you for these excellent suggestions. I have incorporated all other than the last one about dependency map. Creating a new git issue ticket (see #217) and updating the scripts to take care of gwpy, pycbc and others (in future) that might need a similar graph.

[shaloo]

@rossbar - do these look ok? - planning to add these in the case study.

[rossbar]

@rossbar - do these look ok? - planning to add these in the case study.

I only see the dependency graph for gwpy, but it does indeed look very nice! Your script for generating these visualizations of the dependencies is great! :+1:

[shaloo]

Here is the one for PyCBC... Needed to mend the script to take care of PyCBC requirements file intricacies.

[rgommers]

@shaloo I like the gwpy one. for the PyCBC one I think it would be good to exclude six and the nodes that are only connected to six. This is what you did EHT as well.