Category Archives: productivity

Life changing tips for screen sharing with Keynote/Zoom

I just stumbled across these on the internet and they are both great. These are for Keynote (on macs) but there are probably equivalent settings on Powerpoint.

1. If you want to be able to switch apps while in presentation mode (e.g. to see the Zoom window). Look at this guide on the Zoom documentation. There is also a setting where you can make your cursor visible at all times so you can use it to point at things on your slides.

2. If you want to play your slideshow in a window (so it doesn’t take up the whole screen). Go into this mode first, then share the keynote window from Zoom. (Downside: you won’t be able to see your “presenter view” from keynote, just the slides at they appear to others.

How to merge ICS files for bulk import of calendar events

Have you ever wanted to add a bunch of events to your calendar all at once? If you have a bunch of individual calendar invite files (.ics), there’s no way to select a bunch of them an import them in one go (at least not in the Apple or Google calendars). But by poking around in the terminal, I figured out a way to do it!

Continue reading

Debugging MPI with Xcode Visual Debuggers

The Xcode visual debugger is really nice and easy to use. It turns out it’s possible to get it to play well with MPI code (although it may not work for actually multithreaded processes). This seems to be pretty buggy, but it does work. I’m not sure how useful this guide is to others, but honestly I’m writing it to remember how to do this in the future.


mpic++ is just a wrapper for the system C++ compiler, but on my system is defaults to g++ and we want to switch to c++ (the Apple C compiler). To start, we use the --show-me:compile flag with our usual compilation command
mpic++ --show-me:compile *.cpp
This doesn’t actually compile the code, it just tells you the command that would have actually been executed with the C compiler. In my case the output is:
g++ config.cpp main.cpp mtrand.cpp -I/usr/local/include -L/usr/local/lib -lmpi
We’re going to take all those flags and put them after the Apple C compiler like so:
c++ -g config.cpp main.cpp mtrand.cpp -I/usr/local/include -L/usr/local/lib -lmpi
Don’t forget to add the debugging flag -g. This command produces a binary file a.out. Before we can run it, we need to get Xcode ready.

Launching the Debugger

Open the Xcode project. On the menubar, select Debug–>Attach to Process by PID or Name…

Screenshot showing menu selection.

In the resulting window, enter the name of the executable (this this case a.out) and click “Attach”.

Screenshot of debugging attachment dialogue.

Now we’re ready to actually run our simulation using the normal command in the terminal:
mpirun -np 1 ./a.out

When you switch back to Xcode, you should be able to use the debugging interface like normal. If it doesn’t come up automatically you may have to click on the debugging logo in the navigation bar on the left side of the window (circled below).

Xcode navigation bar with the debugging tab circled.

Trouble attaching to process?

For some reason I find that Xcode cannot attach to the process using this procedure often with an error like “Message from debugger: error 1”. I haven’t been able to figure out exactly why this happens or how to avoid it altogether. My use case is way outside what Xcode is designed for (i.e. building iOS apps). Overall I found that using the stop button within Xcode to kill the process (rather than killing it from the terminal) seems to make this problem less likely, but it still happens.

Once this problem occurs, the only solution I have found is to recompile the binary, naming it something else using the -o othername.out flag (renaming an existing binary won’t work), attaching the debugger to the new binary and then running the new binary.

Cover of the book "Rest"

Book Review: “Rest” by Alex Soojung-Kim Pang

by Alex Soojung-Kim Pang

A few months ago I had the pleasure of reading “Rest: Why You Get More Done When You Work Less” by Alex Soojung-Kim Pang. The core thesis of the book is that there is a limited amount of focused creative work that one can do each day, and that rest is an integral part of creative work. The book is a delight to read and (unlike many books in this genre) not overly long.

To prove his thesis, Pang relies on a combination of scientific studies relating rest and productivity as well as a collection of case studies of famous creative people including writers and scientists. As a scientist, I really appreciate that Pang correctly identifies scientific research as a fundamentally creative task, and seems especially fond of famous physicists.

The “resting” brain is not inactive. During rest the subconscious mind continues processing the ideas that the conscious mind was thinking about, but it does it in a different, freer way. This explains the often-reported phenomenon of getting your best ideas while you’re in the shower, or while out on a walk. Working more hours isn’t a guarantee of accomplishing more:

A survey of scientists’ working lives conducted in the early 1950s … graphed the number of hours faculty spent in the office against the number of articles they produced. … The data revealed an M-shaped curve. The curve rose steeply at first and peaked at between ten to twenty hours per week. The curve then turned downward. Scientists who spent twenty-five hours in the workplace were no more productive than those who spent five. Scientists working thirty-five hours a week were half as productive as their twenty-hours-a-week colleagues. From there, the curve rose again, but more modestly.

Across disciplines from science to writing to music, the limit for focused creative work seems to be 4-5 hours per day. A study of violin students at the Berlin Conservatory found that the best students weren’t those who practiced the most.

“Deliberate practice is an effortful activity that can be sustained only for a limited time each day.” Practice too little and you never become world-class. Practice too much, though, and you increase the odds of being struck down by injury, draining yourself mentally, or burning out. To succeed, students must “avoid exhaustion” and “limit practice to an amount from which they can completely recover on a daily or weekly basis.”

Pang also discusses the roles different kinds of breaks—detachment, deep play, sabbaticals—play in enhancing creativity. It’s worth noting that rest in this view need not be passive.

I’ve taken Pang’s message to heart and the results of my small uncontrolled study confirm his thesis. Over the past few months I have tried to make more time for rest. That has taken many forms. During the work day I make sure to take breaks for my mind to wander. Just a few minutes at a time, but it seems to help. I have also cut back on podcasts so I have more time with my thoughts. On the weekends, I find long bike rides very refreshing as a rare time where I am free from electronic distractions. As a result, I now feel more focused and present with the tasks that I am doing. I am spending a bit less time in the office, but I am getting much more science done.

My LaTeX Setup

When I write almost anything related to physics, I use LaTeX. For the uninitiated, LaTeX (pronounced lah-tek or lay-tek, anything but lay-teks) is a markup language widely used in the physics community because it allows authors to create automatically-formatted manuscripts complete with beautifully typeset equations, footnotes, references, figures, captions and more. If this doesn’t sound like something you need, then you can go ahead and skip this post. But if you’re a physicist, you should be using LaTeX. The learning curve is a bit steep, but well worth the efforts. Since college I have used LaTeX for all my technical writing including papers, my dissertation, and ongoing notes on my work. There is no shortage of guides to learning and using LaTeX which I will not try to replicate here. Instead, I will offer a few remarks on how I use LaTeX in my work and some of the tips and tricks I’ve learned over the years.

My setup

Since I am a lifelong Apple fanboy, I do all my work on a Mac. My preferred TeX editor is TeXShop, but I don’t have strong opinions about it, it’s just what I know. The LaTeX distribution for macOS is called MacTeX. The full MacTeX installer is over 3.2 gb, and most of that is for obscure packages and languages that I’ll never need, so I use the smaller installer called BasicTeX, which is only 78 mb. BasicTeX does not include all the packages I need, but it includes a package manager tlmgr that can be used to download any additional packages using the command:

sudo tlmgr install PackageName


For producing my bibliography I use BibTeX, an extension of LaTeX. The beauty of BibTeX is that you need never again concern yourself with the formatting or ordering of your citations because BibTeX does that all automatically. If you want to cite a paper, simply go to the journal’s website, download the bibtex snippet that goes with the paper, copy and paste it into your .bib file, and cite it using the \cite{} command.


One of the best decisions I ever made in my scientific career was to start using git for tracking changes to my papers. Git is open-source version tracking software usually used for programming. It is often used with cloud services like github, but you can also run git locally on your computer. TeX source code is just like any other source code, so you can use git with it just like you would for C++. Using git means that I can always recover my manuscript to a previous state, and I can maintain multiple versions of the same manuscript using branches. I used this feature heavily in my dissertation when I had to prepare two different versions, one for the BU library and one for Springer.

As a writer, it is always a challenge to “murder your darlings,” i.e. delete text that no longer makes sense, no matter how lovingly it was crafted. Whenever I set out to do this, there’s always a voice in the back of my head saying “but what if you want this later?” Using Git is a great way to silence that voice because I know I can always get it back, even if I never end up needing to.

A few tips for Git + LaTeX:

  • Write each sentence in your .tex file on its own line. This makes tracking your changes easier.
  • Don’t commit your PDF, at least not every time. Git is not as efficient at keeping track of changes to PDFs and your repo may end up requiring a lot of storage space.
  • Don’t track the auxiliary files generated by tex like .aux, .log, etc.
  • You can also collaborate on papers using a private git repo on a service like github.

A few of my favorite LaTeX packages

All these can be downloaded through texlive manager. The links below are just for finding the documentation.

  • REVTeX: APS’s LaTeX package that automatically formats documents in the style of each of their journals.
  • cleveref: A package that automatically inserts the appropriate text just as “Fig.” or “Eq.” in front of your figure and equation references. Just replace
    Fig. \ref{f:someFig}


  • braket: Effortless Dirac bra and ket notation.
  • hyperref: Automatically turns all your citations, footnotes, equation references, etc, into hyperlinks to the appropriate place in your PDF. A must-have for big documents, especially those with a table of contents.
  • amsmath: Among other things, includes the align environment, which is essentially a drop-in replacement for the equation environment that makes it easy to format multi-line equations.
  • latexdiff: A program that takes two tex source code files and outputs a source file that highlights the changes between the two versions, showing new text in blue and striking through deleted text. This is much easier to read than directly comparing the tex source files. On the command line execute:
    latexdiff oldVersion.tex newVersion.tex > difs.tex

    You can then compile difs.tex as you would any other tex file.

How do you use tex? What are you favorite packages and styles? I’m always looking to learn more.