GDR Quantum Dynamics in Dijon and GSDE10 in Santa Marinella

2010-06-30

Teaching period is over. During this period I was invited to give two talks but I didn´t have until now the opportunity to write about these here. In both occasions I talked about my favorite subject at the moment: integrable Hamiltonian systems with codimension-1 singularities.

Firstly, I was invited to give a talk at the second meeting of the GDR Quantum Dynamics that took place 24-26 March 2010 in Dijon. Besides my presentation, I had the opportunity to discuss with my colleagues in Dijon (Dominique Sugny, Pavao Mardešić, Michèle Pelletier, and Hans Jauslin) and with Dmitrií Sadovskií.

DSC_2732

Secondly, I was invited to give a talk at the GSDE10 meeting that took place 17-22 May 2010 in Santa Marinella, a small seatown close to Rome. Giuseppe Gaeta is one of the organizers of the GSDE meetings and also of the more well known SPT conferences, the next one taking place 5-12 June 2011 in Polignano near Bari. In the meeting I had discussions with Ferdinand Verhulst and Giuseppe Pucacco, and I learned about the work by several Italian groups on symmetries of ordinary and partial differential equations. My photos from the meeting are available on Flickr.

Giving a talk in GSDE10

Printing on the 4th floor from Mac OS X

2008-11-26

These are instructions for setting up computers running Mac OS X 10.5 (Leopard) to print to the IWI printer on the 4th floor of the Bernoulliborg. The printer is a Kyocera FS-3900DN which for entirely mysterious, to me, reasons is available in the Netherlands as Océ WP35.

Download and install the drivers. You need the file Kyocera OS X 1045 v1.0a.mpkg.zip. Then, in the Mac´s System Preferences select the panel Print & Fax. Click on the + button. In the window that appears click on Default, select Oce_pr2 from the list of printers and press Add. In the next dialog press Continue. Succes!

Update Feb. 16 2010: There is a problem with the Kyocera drivers under Mac OS X 10.6 (Snow Leopard). There are two possible solutions. The first is to use the Kyocera 3800 drivers that come with 10.6. I don´t run 10.6 so I only have second-hand knowledge that this actually works. A second possible solution for which I don´t even have second-hand knowledge that it works is to download and run the OSX 10.6 Permissions Fix program available here from Kyocera. Detailed instructions are also available.

Update Jun. 11 2010: I now run Snow Leopard, and I can verify that the official Kyocera driver for FS-3900DN together with the permissions fix work perfectly. Furthermore, I have now changed the way I setup the printer so that I can print also through the wireless network (RuG-FN2). For this, instead of going to the Default pane of the Add Printer window, go to the IP pane. In Protocol choose Internet Printing Protocol (IPP), in Address fill in 129.125.68.42, and in Queue fill in ipp/FWN-5161-0400-OCEWP35. You can also change the name to something more recognizable. Finally, you have to manually choose the printer driver.

New publications

2010-03-02

Three new papers have been accepted for publication recently. First, a review paper with Dmitrií Sadovskií has been accepted for publication in Reviews of Modern Physics. The subject of the review is the recent advances in the study of the hydrogen atom in electric and magnetic fields that were made possible by adopting the point of view of global analysis of (near) integrable Hamiltonian systems. A paper on bidromy with Dominique Sugny has been already published in Journal of Physics A. In the paper we describe the classical actions and the joint quantum spectrum of integrable Hamiltonian systems with bifurcation diagram that contains a swallowtail catastrophe. Finally, a paper with Elie Assémat, Marc Joyeux, and Dominique Sugny has been accepted for publication to Physical Review Letters. In this paper we study the common appearance of fractional monodromy and bidromy in the vibrational spectrum of HOCl.

2009 review

2010-01-11

I´m just back from my vacation trip to the very beautiful Iceland, so the new year (in terms of work) starts a little late. I have realized that time plays very strange tricks with my memories and as I grow older things become worse. In particular, when I look back I tend to underestimate the things I have achieved in any given time period and how much I have developed as a researcher and as a person. Writing some of these things down is the best solution to keep things into perspective. So, I am starting something that I will try to make a tradition in this journal: a review of the past year.

Here we go for 2009.

  • Finished four papers: 1 paper has been accepted, 2 papers are on the verge of being formally accepted, and 1 is being refereed.

  • Had the opportunity to work with some great people: Henk Broer and Igor Hoveijn in Groningen, Carles Simó in Barcelona, Dmitrií Sadovskií in Dunkerque, Dominique Sugny, Pavao Mardešić, and Michèle Pelletier in Dijon.

  • Organized a workshop at the Lorentz Center in Leiden together with Jonathan Robbins, Dmitrií Sadovskií, and Holger Waalkens.

  • Attended three more workshops.

  • Gave 5 talks: Utrecht, Barcelona, Luminy, Leiden, and Athens.

  • Visited Barcelona twice (the first time for 3 days and the second for 2 weeks) for a collaboration with Carles Simó. Learned a lot about Taylor integration methods.

  • Visited Boulogne-sur-Mer for a week for a collaboration with Dmitrií Sadovskií.

  • Taught two courses.

  • Refereed 3 papers.

  • Applied for, but failed to get, an NWO Vidi grant. At least my proposal was judged to be «worthy of funding on the basis of its merits» (sigh!).

  • Redesigned my personal website and rewrote the code that runs the website to use WSGI.

  • Wrote a lot of Emacs Lisp. My favorites: code to show many TeX math commands in Emacs using the corresponding Unicode character (for example \infty shows as ∞, \ge as ≥, etc.) and a small package to interact with the Simplenote application.

  • Understood the finer technical aspects of low light photography and why my G9 is absolutely not suitable for it (in short: too many megapixels, small sensor, not the widest possible aperture at ƒ/2.8).

  • Visited (or re-visited) for vacation some beautiful places: Nord-Pas-de-Calais, Lisbon, Switzerland (Bern, Geneve, Lausanne, Zermatt), Liechtenstein, Innsbruck, Santorini. Iceland was the most beautiful place I visited but technically this was in 2010 so it doesn´t count.

I already have some concrete plans for 2010 on the problems I want to work on, there are papers that have to be finished, and invitations to workshops that I will attend. Life goes on.

Writing numerical code using C and Python

2009-11-28

The main requirement for numerical code is that it must be fast. This means that numerical code is usually written in some “low-level” language such as C or Fortran. Such code can be highly optimized but low-level languages are not very expressive (where expressiveness is defined as the inverse of the number of lines of code that is necessary in order to express a program). Thus they are not very well suited to other tasks, such as data I/O, command line argument parsing, graphics, and user interaction that are peripheral to, but nevertheless important for, the computation and where speed does not play the primary role.

C++ is being often used in numerical programming since, due to its multi-paradigm nature, it is expressive enough to support high-level tasks (a library like Boost can be extremely helpful here) while at the same time it can produce highly optimized code. Despite these benefits, C++'s complexity, static typing, and the edit-compile-link cycle create severe impediments to exploratory programming.

Exploratory programming is possible in dynamic (often called “scripting”) languages such as Perl, Python, and Ruby. Such languages offer great, easy to use libraries for high-level tasks. Moreover they offer very expressive language constructs and a rich repertoire of built-in types (lists, dictionaries, etc.) that make exploratory programming not only possible but even a joy. Of course the problem with using such languages for numerical programming is that they are abysmally slow.

But since we have languages that are very well suited to low-level tasks and languages that are very well suited to high-level tasks why not combine them and program each task in the appropriate language? This is a reasonable idea but its success or failure in the real world depends strongly on how easily this can be done. Python has had for several years a number of solutions in this field. At one side the official, but rather low-level, Python/C API. At the other side projects like SWIG and SIP that help in writing Python bindings to C libraries. Although they work, and I have used SWIG in some of my previous projects, I was never quite satisfied.

A recent addition to this field is ctypes which is the easiest way to write Python bindings to low-level (C or Fortran) libraries. The bindings are actually written in Python so we get all the benefits of using a beautiful, expressive language. Using ctypes has changed the way I write numerical code. Usually, I would just write the whole thing in C++ and learn to accept the pain. Now, I start by writing the most computationally expensive part of the code, usually the ODE integrator, in C. Then I build my programs in Python and I call the integrator through ctypes. Since I write the programs in Python I enjoy all the benefits that the language provides. After I am satisfied that things work correctly, I may translate some other computationally intensive parts of the code to C and call them from my Python program through ctypes. This type of development allows me to test several ideas during an exploratory phase and then optimize for speed by rewriting the critical parts of the code in C. This method of building programs through successive rounds of experimentation and optimization is extremely productive.

Writing the bindings is actually trivial. For example, the C function

double hatom_2d_energy(double x[4]);

which has been compiled into the dynamic library libhatom_2d.dylib, can be imported in a Python program with the following code

from ctypes import *
lib = CDLL("libhatom_2d.dylib")
point_t = c_double * 4
lib.hatom_2d_energy.argtypes = [point_t]
lib.hatom_2d_energy.restype = c_double

and then called as

x = [0.0, 0.12, 1.1, 0.2]
print lib.hatom_2d_energy(point_t(*x))

The binding itself is defined through the two member variables argtypes and restype. The whole code is still ugly, but it can be hidden in a module and a wrapper function can be defined which is then imported from the module. The only real problem with ctypes is that argtypes and restype must be defined for each C function to be used in the Python program. This can be a problem for writing bindings to a C library with a few hundred functions but it´s not a problem I had to face.