Author Archives: iaizzi

Great resource: Beall’s list of predatory journals

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 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.

Article recommendation: Do quantum spin liquids exist?

I recently read this phenomenal Physics Today article by Takashi Imai and Young Lee, “Do quantum spin liquids exist?” Physics Today 69, 8, 30 (2016). It’s a couple years old, but it’s a clear, relatively non-technical description of quantum spin liquids (QSL) and why they’re interesting along with a easy-to-follow history of developments in the field up to today. This provides some much needed clarity, especially since journal articles about QSL often use varying definitions of QSL.