$ mkdir build
$ cd build
$ cmake ..
()-- Configuring done
-- Generating done
-- Build files have been written to: /home/amckinstry/deb-packages /cdat/cdat-6.0.alpha/build
$ make
$

The problem is, 'make' does nothing. A Makefile is generated by CMake, which calls cmake which calls make again on ./CMakeFiles/Makefile2 ... which does nothing useful. Apparently the CMake is supposed to put useful stuff in there, but doesn't. What puts stuff into Makefile2, and where should I pick up the bugs trail?

You can make entries public, and I've tested a public address for this: http://diaspora.sceal.ie/u/amckinstry which looks ok, a bit plain for the moment, but I'll work on that later. The problem has been the atom feed is garbage. (It's putting the content into both the Subject line (as unadulterated MarkDown, no less), and into the content).

So, I've put the old blog back up for the moment. While I debug some Ruby on Rails, not a language i'm too familiar with ...

Note: only logged in DIASPORA users can leave notes on the Diaspora site, but go to the login page and registrations are open. At least until spammers notice...

This paper is a follow-on to Kleidons work on the thermodynamics of the climate, where he points out that the free energy is the important measure of what energy can be generated by renewables. The free energy of the atmosphere is on the scale of hundreds of TW, he argues, much less than the heat energy of ~10^5 TW that comes from the sun. He argues that not enough attention is paid to the free energy budget, and argues that from MEP theory that free energy flows through different geophysical processes are more important than people currently think: such energy and momentum flows then lead to faster depletion of gradients than people currently use in their models. Frequently we use "diffusive-like" approximations to stuff we can't explicitly handle,such as convection and eddies below the resolution of our computer models.

That the free energy budget, and small-scale processes need more detailed study (such as the transfer of momentum and energy from wind to water), I agree. But paradoxically, MGK10's estimates based on diffusive processes are what gets it into trouble.

The critiques (e.g. Jacobsen and Archer) seem to concentrate on the estimates for diffusive and other energy losses (eg. wake fields) and climatic consequences are very loose, and out by factors of 50-100. They also ignore the fact that using wind as a substitute for more destructive energy sources produces a net gain, climate-wise. Based on these numbers, the real limits on wind power are more limited by where we can realistically place turbines, and the use and availability of rare earth metals in turbine magnets (MW sized turbines use over a ton of neodynium each in magnets!)

One of the focuses of research at ICHEC and Met Eireann is wind for wind power: this becomes increasingly important for Ireland as we have more energy production by wind. I've been recently involved in a European project Weather Intelligence for Renewable Energies on investigating weather and climate forecasting needs of wind energy.

In our weather models, we are getting to finer and finer resolutions (down to 2-5 km operationally, but working on 1 km in research), but as yet do not take account of wind energy changes. Modelling the wake turbulence, etc. and other effects of turbines is a 'fluid dynamics' problem done by the wind turbine manufacturers, mostly, in order to lay out turbines in a farm efficiently; this is done on the timescale of metres and seconds, while on the other end of the spectrum work is done in climate research on the changes in potential winds to see if wind energy will change in a few decades. But little is done on 'weather' scales of kilometres, minutes and hours: it turns out there are wind patterns that we don't predict in our models (vortices, etc.; especially for offshore turbines) that affect wind energy production, but would be very useful for wind farm and electrical grid operators to know about. So we should think about adapting our weather models for these.

Either way, it looks like more detailed work on the interactions between atmospheric dynamics and wind farms would be a good thing.

Incidentally, whatever about the alarmist nature of the article, kudos to New Scientist for their linking to papers: they quoted the names of the journals (Earth System Dynamics,Philosophical Transactions of the Royal Society), but where the article was not yet published (or behind a paywall), linked to the Arxiv.org version. More could do this.

Basically the Daíl is stuffed with teachers, lawyers, publicans and the like: those who can postpone a career, run for office knowing that they can safely move back into their old job. Teachers in particular find their posts held open for them until they return. Scientists and Engineers, on the other hand, would effectively be committing career suicide: 5 years out of the industry and your day-to-day knowledge is stale. You are effectively unemployable.

So Mike O'Keeffe from Ircona suggests that we create a retraining fund; basically make the promise to engineers and the like running for office that 'your job is open for you when you return'. The fund would go to their employer to help retrain them back into work for several years after they return.

This fund would be set up by the high-tech industries in Ireland, who could do with people who actually understand those industries (ICT, biotech, etc.), and even just science in the Daíl. How about it?

[Note: this is not to say this is the only, or even most important, fix needed to Irish politics; but it should be straightforward compared to reforming the constitution.]

Earth-based climate modellers have test cases such as Held-Suarez which are used to compare the models, but to date no equivalents are used for exoplanetary models. This work fills that gap for Tidally-locked atmospheres (similar to Zarmina for example, and some 'Hot Jupiters'. I'm particularly interested in the tidally-locked Earth case; it's relevant for my own PhD work.

Incidentally, for a good summary of the different ways we test climate models, see Steve Easterbrook's recent blog entry; he's been doing a tour of major modelling centres, learning how they do things. Worth a look.

Although personally I think GL 581 d, its neighbour, has a better chance of being habitable. Everyone is assuming Zarmina is tidally-locked: that is, it has one side facing the star at all times. This would mean that while one side of the star is scorching hot, the other freezing cold, all you have to do is go to the "Terminator", the part of the planet in continuous dusk (or dawn) to find a nice climate. Not necessarily so: it can be in orbital resonance like Mercury, which rotates in a 3:2 ratio. A better idea is to look below any oceans, if it has them, for life.

Either way, this Gliese 581 is the direction to point a TPF at.

In fact the naming worries started earlier when Frank Selsis asked people to avoid calling the planets he works on "super-Earths" (or should that be Super-Earths?). Dimitar Sasselov had accidentally kicked up a kerfuffle in the media a few weeks back by calling them "Earth-like" planets, when he meant "Earth-sized" planets. Selsis pointed out non-scientists will interpret "super-Earth" to mean "like Earth, only Better!", when we mean its just a bigger ball of rock and ice than Earth. But what to call them?

Well, at least one planet already has a name, sort of: HD 209458b is frequently called 'Osiris'. And there is a published list of possible planet names. But Osiris the Egyptian god is more famous than Osiris the planet, confusing google. And people are going to assume things based on the planet names: are we really going to name a planet Vulcan?

One suggestion was that if we found a system with seven planets we could call them after the Seven Dwarfs, but this was ruled out: don't mention the war (but dwarfs could also mean brown dwarfs!)

At the end of the conference, there was show of hands: who agreed with naming planets? of about 100 present, all in favour, none against. The delegate to the IAU commision on the matter, which had voted against, duly noted. Perhaps we will name them then.

Peter Cox on model complexity

The last talk on Friday was by Peter Cox on Climate change and exoplanet sciences that was far better than expected for the "graveyard shift". One theme of the conference was the need for a 'heirarchy' of models, from simple energy-balance models to full circulation (GCM) models: using progressively more complex models to understand more bits of whats going on. Exoplanet workers mostly use simpler models, progressing now to GCMs, while Earth modellers are moving beyond GCMs to "Earth system" models including biology, etc. Peter pointed out the two styles of work: the exoplanet modelers are short of data, and risk being too speculative. We know little of what the planets are like, and concentrate on implementing physics in the models to see what they might be like. Earth modelers on the other hand are if anything swamped with data: the tendency here is to make the model fit the data, by adjusting parameters until it does so. The danger of this approach is that the model will then not work away from current present-Earth conditions.

Tim Lenton pointed out some work that was done with the Met Office model, where they took the radiative transfer part of the model and tested it for other planets, and paleo-Earth conditions. The model blew up : it wasn't capable of x2 or x4 current CO2 levels. (This has since been corrected).

Over dinner there were interesting discussions on the different styles within the communities. While the underlying GCMs used come from the Earth sciences, its quite common within the exoplanetary community for a researcher to work on all parts of the model: dynamics one day, radiative transfer the next. In Earth climate work people have become more specialized and someone is a 'radiative transfer' person, and won't touch other parts of the code (even if they can follow them in the huge codes we have today!).

On the other hand, there is a greater tradition of model inter-comparison in Earth sciences, where we compare the model outputs to each other for some known test cases ( Held & Suarez, the CMIP5 project, etc.) Apart from some initial work by Emily Rauscher, little has been done on this in exoplanetary models; it was agreed more of this would be a good idea. Radiative transfer (the interaction of 'sunlight' with the atmosphere, where it gets absorbed, scattered and re-radiated) in particular seems to be an area that could benefit from this.

Ralph Lorenz pointed out the lack of "real paleo-Earth" climate work at the moment. While geology has inspired a lot of work on the atmospheric composition, what with the different gas mixtures (meaning earth-model radiative transfer codes don't work) and the faster dynamics meaning super-rotation could apply (Earth's day was about 8 hours long in the Archean era), we don't have a model of the climate yet. It looks like we should treat Earth as an exoplanet.

Now in HPC and climate in particular, codes are typically linked statically: partially for robustness, but mostly for speed (more on which later). So, I'd like to link this statically, as I have tens of terabytes of data to process. Now, mostly I've been linking using pkg-config:

  gfortran -o nemo-rewriter nemo-rewriter.f90 `pkg-config --libs --cflags nemo cmor`

pkg-config assembles the libraries. For dynamic libraries, the netcdf and cmor libraries are themselves linked to dependencies. But in the static case, all dependencies need to be on the link line, which is more complex. Never mind, it should be possible with:

  gfortran -static -o nemo-rewriter nemo-rewriter.f90 `pkg-config --static --libs --cflags nemo cmor`

This should work by assembling all the required static libraries, via pkg-config dependencies. Unfortunately not every package has a .pc file, and so this fails: As of version 4.1 NetCDF allows a URL instead of a file to read, and hence depends on curl to retrieve the file. Curl has no pkg-config .pc file describing its libraries, and it fails.

Never mind, lets assemble the static libraries by hand. Debian provides static versions of libraries in the -dev packages. Can I assemble a statically-linked program ? For this I need:

• NetCDF needs libnetcdff.a and libnetcdf.a directly.
• NetCDF needs HDF5: libnethdf5_hl.a and libhdf5.a for version 4 files.
• CMOR2 needs: libcmor2.a
• CMOR2 depends on libudunits2.a, to convert between physical units.

Now here it gets interesting. To handle secure communications and authentication, curl has some complex dependencies. It has two versions. Pick the gnutls one for example:

• libgss.a for Generic Security Services.
• libgss needs libidn.a for Internationalized Domain names
• libgss needs libshishi.a for Kerberos
• libshishi.a needs libgpg-error.a
• libshishi.a needs libgnutls.a
• libshishi.a needs libtasn1.a
• libshishi.a needs libgcrypt.a
• libshishi.a needs libresolv.a
• libcurl.a needs libssl.a
• libcurl.a needs libssh2.a
• libcurl.a needs libldap_r.a
• libdlap_r.a needs liblber.a
• libldap_r.a needs libsasl2.a. Which access databases, so ...
• libsasl2.a needs libmysqlclient.a
• libsasl2.a needs libpq.a
• libsasl2.a needs libdb-4.8.a
• libsasl.a needs libsqlite.a
• libssl.a needs libcrypto.a
• libcrypto.a needs libz.a
• libcurl.a needs libdl.a
• libcurl.a needs libcom_err.a
• libcurl.a needs libkeyutils.a
• libcurl.a needs libgssapi_krb5, which is in dynamic form only
• libcurl.a needs libkrb5crypto, which has no static library

I may have missed some out, having stopped because there is no static implementation of Kerberos on Debian. But still, the idea that a simple little fortran proggie will statically link in four database libraries is silly. It appears to be no longer possible to simply statically link a program in Debian, and definitely not via pkg-config, because so many dependencies do not yet have configuration files.