Just presented at the Annual Meeting of the Physical Society of Taiwan

I just presented a talk “Quenching to field-stabilized magnetization plateaus in the unfrustrated Ising antiferromagnet” based on my preprint that I posted on arXiv last week at the Annual Meeting of the Physical Society of Taiwan at National Pingtung University in Pingtung, Taiwan. I haven’t gotten around to making a post about this paper yet (that is coming soon), but in the meantime I will post my slides from this talk here. My slides included some movies of the process of freezing in to magnetization plateaus. Since PDFs can’t include movies I will post the movies below.

Gif of Ising spin configurations arriving at a frozen plateau state.
The spin configuration over time starting from a random (T=∞) state and doing single spin flip Metropolis updates at T=0 and h=1 until we arrive at a final frozen state. Individual spin states are denoted by the (+) and (-); the background shading shows which of the antiferromagnetic ground states each site is in. In the final frozen state the domain walls are all straight lines or corners with (+) on the inside.

Gif of Ising spin configurations arriving at a frozen plateau state.
The spin configuration over time starting from a random (T=∞) state and doing single spin flip Metropolis updates at T=0 and h=3 until we arrive at a final frozen state. Individual spin states are denoted by the (+) and (-); the background shading shows which of the antiferromagnetic ground states each site is in. In the final frozen state the domain walls are all diagonal or square-wave-like with excess (+) spin.

APS Congressional Visit Day 2020

APS Congressional Visit Day 2020

This week, I am in Washington DC for the APS Congressional Visit Day and Annual Leadership Meeting. We started on Wednesday with the Congressional Visit. APS broke us up into teams by region. I’m a Massachusetts voter, so I joined a team of people from Massachusetts and Connecticut. We had six meetings with the offices of Massachusetts Senators Ed Markey and Elizabeth Warren, Connecticut Senators Chris Murphy and Richard Blumenthal along with House Representatives James Himes and Rosa DeLauro.

Continue reading

Women are no better or worse than men at doing physics, but they are, however, more persistent.

Myriam P. Sarachik, 2020

Today I attended an awards dinner for several APS awards. Myriam P. Sarachik received the APS Medal for Exceptional Achievement in Research and gave a truly insightful acceptance speech and I just had to share this specific quote. She told a number of stories of the obstacles she faced to building a scientific career and how she overcame them through luck, talent and persistence. A great lesson for us all!

Footnotes and citations should look different

Overall, I think physics is lucky to have its premier journals (Physical Review) be run by our own nonprofit professional society—APS. I think that explains, at least in part, why the arXiv has been so successful in physics and why similar efforts have floundered in other fields.

All that said, I have one bone to pick with the Physical Review journals: they insist that footnotes should be denoted in the same manner as citations [1,2]. Citations and footnotes serve very different purposes, and I both use and consume them in very different ways. When I’m reading a paper, I often read the footnotes, especially if I’m trying to totally understand a passage. I almost never look at the citations on my first reading. As a reader, I love footnotes! They’re a great way to add context, clarifications, parenthetical remarks, or definitions without interrupting the flow of your argument. Citations, on the other hand, are for backing up your claims or giving proper credit. If you mistake a footnote for a citation, you might miss some useful information or you might wrongly assume that the claim is backed up elsewhere in the literature [3]. Finally, I prefer footnotes to endnotes because footnotes keeps the information nearby, rather than forcing readers to flip pages back and forth.

In summary, Physical Review Letters and A, B, C and D: please follow Physical Review E‘s lead and allow separate footnotes!

Just one section called references:

[1] Waldron et al. “The Physical Review Style and Notation Guide” APS 2011 (a citation)
[2] At least for Physical Review B and Physical Review Letters, which are the PR journals I use. Phys Rev E does allow separate footnotes. (a footnote)
[3] For example, if you mistook [2] for a citation, you might not have noticed my caveat about which specific journals exhibit this problem.

Update 2020-03-12

Let the record reflect that after I posted this I heard that PRB does, in fact, allow separate footnotes. I tested this with my most recent paper and I now have experimental proof.

Great resource: Beall’s list of predatory journals

Update 2020-01-24: Beall’s list has a new home: https://beallslist.net/

With your academic email address posted online, you’ll be flooded with sketchy offers inviting you to submit your manuscript to open-access journals with legitimate sounding names like “British Journal of Science” or “Cancer Research Frontiers”. These predatory journals typically do little or no peer review. One pair of scientists was even able to get a paper containing only the repeated text “Get me off your f___ing mailing list” published in the predatory International Journal of Advanced Computer Technology.

The proliferation of these journals is perhaps the chief disadvantage of the move towards open access since, in the digital age, setting up a website is nearly free, and open access journals need not convince any librarians to pay for subscriptions to make money. Instead these ‘journals’ charge huge fees to publish and conduct shoddy peer review or none at all. Some are less directly predatory, but are instead “vanity press” where they get you to pay a fee to publish your thesis with them with little editing or review.

You might also find yourself invited by [person you’ve never met/heard of] to give a talk at [prestigious conference you’ve never heard of] organized by [not a university or professional society]. When you go to register, you’ll find that it’s bizarrely expensive. I think that at least sometimes conferences are real, but like the predatory journals, they are just doing it for a profit.

At least in the case of the predatory journals, Beall’s List of Predatory Journals and Publishers (now located here)provides a great way to check if the journal is a known scam so you can end that email to your spam folder without a tinge of fear that you’re throwing away a legitimate offer. Two notes of caution here: (1) obviously just because it isn’t on the list doesn’t mean everything is above board, so still do your due diligence and (2) on the Beall’s List, you have to click through publishers, standalone journals and vanity press and search each separately.

New paper: Bose-Einstein condensation of deconfined spinons in 2D

My new paper, Bose-Einstein condensation of deconfined spinons in two dimensions, is finally live on arXiv! (arXiv:1909.01594)


Almost all phase transitions are described by a theory known as the Landau-Ginzburg-Wilson (LGW) paradigm, which describes the phase transition in terms of an order parameter that also describes the ordered state (e.g. a transition to a ferromagnet is described by the magnetization). There is therefore great interest in find examples of phase transitions that do not obey this paradigm. Growing numerical evidence suggests that the transition between the Néel antiferromagnet (AFM) and valence-bond solid (VBS) in certain quantum magnets may be such a transition. Since the Néel AFM and VBS break unrelated symmetries (SU(2) and Z4), LGW predicts the transition between them will be first order. Extensive numerical studies, however, strongly suggest that it is continuous. Instead, this transition appears to be described by deconfined quantum criticality (DQC).

In DQC, the critical point is not described by either order parameter, but instead by emergent fractionalized excitations, in this case spinons, which are spin-1/2 bosons (crazy, right?). Away from the critical point spinons are confined inside conventional magnon excitations (like quarks in a proton), but at transition they deconfine. The existence of deconfined quantum criticality remains controversial.

In this paper…

… we add a magnetic field to the DQC point to produce a Bose-Einstein condensate (BEC) of magnetic excitations and use thermodynamics to determine if they are spinons or magnons. My collaborators, Harley Scammell and Oleg Sushkov, developed a quantum field theory approach to predict the low-temperature behavior of a spinons in a magnetic field. We found that the field causes the spinon behavior to differ dramatically from magnons. Using my numerics, we show that the magnetic excitations we observe must indeed be bosonic spinons. This constitutes the first evidence for a BEC of spinons and provides more evidence for DQC theory.


The transition between the Néel antiferromagnet and the valence-bond solid state in two dimensions has become a paradigmatic example of deconfined quantum criticality, a non-Landau transition characterized by fractionalized excitations (spinons). We consider an extension of this scenario whereby the deconfined spinons are subject to a magnetic field. The primary purpose is to identify the exotic scenario of a Bose-Einstein condensate of spinons. We employ quantum Monte Carlo simulations of the JQ model with a magnetic field and perform a quantum field theoretic analysis of the magnetic field and temperature dependence of thermodynamic quantities. The combined analysis provides compelling evidence for the Bose-Einstein condensation of spinons and also demonstrates an extended temperature regime in which the system is best described as gas of spinons interacting with an emergent gauge field.

See you at ISEAS 7 at Tamkang University

On 27 June I have the honor of being an invited speaker at ISEAS 7: Frontiers in Materials Science at Tamkang University in Tamsui, Taiwan. My talk will be titled: Accessing quantum criticality with magnetic field effects: metamagnetism and deconfinement. I’m very much looking forward to the workshop and meeting the other attendees. Thanks very much to Prof. Chao-Hung Du of TKU for the invitation!

Seminar at CSRC

Rubem Mondaini was kind enough to invite to visit his group and give a seminar at the Computational Science Research Center–Beijing. My talk, “Accessing Quantum Criticality with Magnetic Field Effects: Metamagnetism and Deconfinement” covered all of my work on the J-Q model, the saturation transitions in 1D and 2D (metamagnetism and zero-scale-factor universality) up to the latest updates on my work with Harley Scammell and Oleg Sushkov studying thermodynamics of field-induced spinons at the deconfined quantum critical point in the 2D J-Q model. I got some great feedback that will help me put the finishing touches on my manuscript.

After the seminar I had chance to meet with Rubem’s students and postdocs, Chen Cheng, Sabyasachi Tarat and Can Shao and learn about the fascinating things they are working on. After that, a delicious dinner!

I didn’t remember to get a picture of me at my talk, but I did get a photo of all of us out to dinner. I hope to be back to CSRC soon!

Photo from dinner
Dinner with (from left to right) me, Can Shao, Nvsen Ma, Chen Cheng, Rubem Mondaini and Sabyasachi Tarat.

Title: Accessing Quantum Criticality with Magnetic Field Effects: Metamagnetism and Deconfinement

Abstract: Simple models of interacting quantum spins (like the Heisenberg model) are remarkable tools for understanding strong quantum fluctuations, but relatively few studies have considered the effects of external magnetic fields on these systems. I investigate the influence of magnetic fields in the J-Q model, an antiferromagnetic Heisenberg model with an added 4-spin interaction (Q). This model is known to harbor a direct, continuous phase transition between the Néel state and a valence-bond solid. This transition is believed to be an example of deconfined quantum criticality, where the excitations are exotic fractionalized particles known as spinons (S=1/2 bosons). We study the thermodynamics of the excitations and find direct evidence that they are indeed fractional. Separately, we also find that the four-spin term changes the nature of the saturation transition from “zero-scale-factor” universality to metamagnetism (magnetization jumps).

How to write a good README?

Documenting your code might seem like a time-wasting distraction. It’s very easy to convince yourself in the moment “I’ll totally remember how this works” or “it should be obvious what this line does.” I’ve done it myself, and then been totally confused by my own code when I go back to it a few months later. Comments within the code itself are an important form of documentation, but this post will discuss a different form: the README.

What is a README?

You’ve definitely already seen a README: they’re the text files that introduce a project and briefly explain how it works. Whenever you go to a git repo on Github or Gitlab (like uni10 or Firefox) the README serves as the landing page, but you’ll also see README files almost any time you download or install software. The README is the first stop for anyone that will use your code. If you design it well, it might be the last stop too:

Your documentation is complete when someone can use your module without ever having to look at its code. … Remember: the documentation, not the code, defines what a module does.

–Ken Williams (source)

Why do I need to write a README?

Code is only as useful as its documentation. As scientists, we have an extra responsibility to document our code because our code is basically like part of an experiment. It is crucial that your code is an accurate record of what you did, even if you think you are the only person that will ever use your program. In our group the primary problem is ensuring that your code is usable by someone else after you leave. Perhaps another student will need it, or we might need to recheck some calculation.

Of course, often other people will use your code, and a well-written README can help them understand how it works, what its limitations are, and how to use it. The selfish reason to write one is for yourself in the future. Perhaps you know there is some issue with your program, like the parameter J cannot be set to a number greater than 2. That might be fine right now, but will you remember that when you have to rerun your code a year from now? Another good example are dependencies, especially if you had to install anything special. If you write those down right away it will be easy to get your code running on a different machine or after an operating system upgrade.

How to I write a README?

There is no single best answer here. The most important thing is that you do write one. You might think that its obvious how to compile and run your code, but someone new might be totally lost. Little things like compiler flags can really trip a new user up.

What should it include?

In the following subsections I provide some examples of sections you may want to include in your README file.

There is no shortage of README templates out there. These are a good place to start, but computational physics codes have unique needs, so I posted a template on Gitlab you can use as a starting point if you like.


At the very top you should have a brief introduction that includes:

  • Program name
  • Name of author(s)
  • Contact information (email, website)
  • A brief description of what your program does
    • What technique it uses
    • The model it studies
    • What it’s for (why would someone want to use this program?)
  • Copyright notice. I’m not an expert on licenses, so I don’t have much advice here. To keep it simple you can just say “Copyright YOUR NAME YEAR”
  • Links to more extensive documentation elsewhere (papers, examples, etc).

Quick Start

Instructions to quickly get started with your program, e.g. how to compile and install with default settings and how to run it (it’s useful to include an easy way to test if they compiled and installed it correctly.


What does your program assume about the system? You don’t necessarily need to test rigorously, but you can at least say what system you developed your code on and what compiler you used. Write these down as you write your code so you don’t have to remember them lately. Other examples of dependencies:

  • Libraries (especially anything you had to install, like MPI)
  • Anything platform-dependent
  • A specific compiler required
  • Other external programs
  • uni10

Program Files

List your source code files and any auxiliary files, where they are located and what they are for.


What inputs does your program require? Do you specify the parameters of the simulation as command line arguments or are they in a file? What is the format of the file? Which parameters are optional? What are the default values?


If it runs properly your program probably produces data. Is that data displayed on screen? Written to disk? Returned by a function? What format is the data in? How is it normalized?


This section definitely distinguishes computational physics code from ordinary programming. You don’t need to provide a full biography, but some links to papers that describe the method you’re using in detail, or papers you wrote using this program would be great.

Known Issues

Is there anything about your code that doesn’t work? Maybe J cannot be set to zero, maybe there’s a small memory leak, or a segfault that occurs under specific conditions. Depending on the bug, you might not really need to fix it, but it’s definitely important to tell the user so they aren’t caught by surprise (in some cases the user may be you in the future).

Formatting with Markdown

You will probably want to write your README in Markdown. Markdown is a simple way to format a text document (as opposed to markUP, get it? 🤔). The idea of Markdown is to allow minimal formatting while while remaining readable as plain text. You’re probably already familiar with Markdown since it is commonly used for simple text formatting on platforms like Slack. Both Github and Gitlab support Markdown. If you use a mac you can even get “Quick Look” (using the spacebar to view a preview of a file) to display correctly formatted markdown text using my guide here.

I’m not going to do a Markdown tutorial here (instead see the links in the resource section), but as a very quick introduction:

Enclose *italic* text within asterisks and **bold** text within double asterisks. You can include inline code using single backticks `like this` or sections of code with triple backticks like so:
int x=5;
cout << x << endl;

A Markdown-formatted file will typically end in ‘.md’. A quick Google search will return countless examples of Markdown editors for any platform.


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.