Archive for the ‘English’ Category

Automatic generation of a C header from Fortran code?

Saturday, October 31st, 2009

Dear Lazyweb,

In my newest project I need to use Fortran routines and variables in C. From the source code point of view this requires only to declare the needed Fortran entities in your C code whilst taking the “right” types of the variables and the name mangling of the Fortran compiler into account.

Here is an example. Consider you have the following Fortran code:

module X
  real, dimension(0:1) :: v
 
  subroutine Foo(A, b, c, &
    & D)
    integer, intent(in) :: a, &
      & B
    real, intent(out) :: C, d
    ! <Foo's body>
  end subroutine
end module X

To use the array v and the subroutine Foo() in C, you need to add (something like) the following declarations to your C source code:

extern float x_mp_v_[2];
 
void x_mp_foo_(int* a, int* b, float* c, float* d);

If only a handful of Fortran routines are needed to be called from C, declaring them by hand may be feasible. This is however error-prone and becomes impracticable for more than a handful of routines. Especially if the routine signatures change frequently.

So what I’d like to have is a tool that generates a C header file containing all declarations of Fortran entities from a given Fortran source file. Or if such tool does not exist, a tool that extracts variable declarations and routine signatures from a Fortran source file into a format that is easier to parse than Fortran itself would also be helpful. Any suggestions?

SLHA shell interface: slha-io.sh

Tuesday, September 15th, 2009

I’m still working with SLHA files and noticed that people are using C/C++, Fortran, or also Mathematica programs for batch manipulation and processing of SLHA files (for example for repeatedly increasing some parameters in a SLHA file, feeding this file to some program and reading its output). For someone experienced with the shell (no, not that shell) this sounds like an easy task doable in a few lines of shell code. There is however no simple way to manipulate SLHA files on the command line.
The script I’m presenting in this post, slha-io.sh, tries to close that gap. Its description is:

This script is a very simple (and stupid) tool to get or set data in SLHA (SUSY Les Houches Accord) files. It can output complete blocks or individual data lines and replace existing data lines with user given input. It is stupid because it does not check after replacing data lines if the resultant file conforms to the SLHA. So care must be taken when using the “set” action.

But as so often, it is best described by examples. The basic things you can do with slha-io.sh are (MSSM.in is the SLHA file in these examples):

$ slha-io.sh MSSM.in get modsel
Block MODSEL            # Select model
 1    0                 # MSSM
 4    1                 # R-parity is violated
Block SMINPUTS          # Standard Model inputs

$ slha-io.sh MSSM.in get sminputs 6
 6   1.729000E+02       # m_top(pole)

$ slha-io.sh MSSM.in get sminputs 6 | awk '{ print $2 }'
1.729000E+02

$ slha-io.sh MSSM.in set sminputs 6 \
  " 6   1.730000E+02       # m_top(pole)"
$ slha-io.sh MSSM.in get sminputs 6
 6   1.730000E+02       # m_top(pole)

Here is another example of using slha-io.sh to create a batch of files where a parameter is constantly increased from 70 to 80 in steps of 0.5:

for NUM in `seq -f "%.8E" 70 0.5 80`; do
    FILE = "m0_$NUM.in"
    cp MSSM.in "$FILE"
    slha-io.sh "$FILE" set minpar 1 " 1  $NUM  # m0"
done

Maybe this script is useful for one or two!

By the way, more sophisticated tools for SLHA I/O are SLHALib and SLHAio.

Vim syntax highlighting for SUSY Les Houches Accord (SLHA)

Sunday, August 9th, 2009

In my diploma thesis I’m working with supersymmetry spectrum calculation programs (primarily SPheno) which use the SUSY Les Houches Accord (SLHA), defined in arXiv:hep-ph/0311123 and arXiv:0801.0045 [hep-ph], for data input and output. To ease editing input files and reading output files with my favourite text editor Vim I wrote a corresponding syntax file for the Accord. It is really helpful for preventing spelling errors of block names (which are partially cryptic) and for navigating and extracting numerical data.

To enable syntax highlighting in Vim for SLHA download the two files slha.vim and scripts.vim. Copy the slha.vim into ~/.vim/syntax/ and copy scripts.vim into ~/.vim/ or if you have already a scripts.vim file append the content of my file to it. Without further ado Vim should now highlight SLHA files. Here is the compulsory screenshot:

vim_slha

If you have further suggestions or found an error in the scripts, please don’t hesitate to contact me. I’ll try to keep the scripts up to date here.

Update 08.08.2010: The syntax file now includes the block names of the Flavour Les Houches Accord (FLHA, arXiv:1008.0762 [hep-ph]).

b is a power of 2

Sunday, November 16th, 2008

One of the most interesting books I’ve read in the past years is without doubt Gödel, Escher, Bach by Douglas Hofstadter. There he introduces TNT and asks the reader to translate the statement “b is a power of 2″ into TNT. My proposed solution, which I wrote down two years ago, is

\sim\exists a: \, \langle \sim\exists c: \, a=(c+c) \, \wedge \, \forall d: \, b=(\mathrm{SS}a \cdot d) \rangle \ .

This is based on the following equation:
\{u \cdot n \,|\, u=2k+1 \, : \, k, n \in \mathbb{N}\} = \mathbb{N} \,\backslash\, \{2^n \,|\, n \in \mathbb{N}\}
Which means that every natural number except powers of 2 can be written as a product of an odd natural number u and a natural number n. This can be easily understood. Just take the prime factors of an arbitrary natural number. If one of these prime factors is odd, the number can be written as a product of this odd prime factor and the product of the remaining prime factors (which can be even or odd). If there is no odd prime factor, all prime factors must be even and since 2 is the only even prime number the original number must be a power of 2.

I’m wondering if my solution is correct and how other people have written this statement in TNT.

Goddies with bts’ “status” and “select”

Sunday, September 21st, 2008

Since I was watching Don Armstrong’s talk about Debbugs’ SOAP interface I wanted to use devscripts' bts to get a list of boinc‘s top five bug reporter. Finally, this is possible with devscripts (>= 2.10.36):

bts status file:- `bts select source:boinc archive:both` \
  | egrep "^originator" | cut -f2- | sort | uniq -ci | sort -n \
  | tail -n5

 2 Riccardo Stagni <unriccio@email.it>
 3 Martin Michlmayr <tbm@cyrius.com>
 6 Robert Millan <rmh@aybabtu.com>
 6 Thibaut VARENE <varenet@debian.org>
10 Sandro Tosi <matrixhasu@gmail.com>

Sweet – Thanks Debbugs and Devscripts maintainers!
And congratulations Sandro (or thank you – whatever you find appropriate)!

Update:
Lucas Nussbaum recently demonstrated how the Ultimate Debian Database (UDD) can be used to assemble cool stats about Debian bugs. This brought me to translate the above shell code into an SQL query for UDD. To retrieve boinc‘s top five bug reporter from UDD, one would use a query like this:

udd=> select submitter, count(*) from (select * from bugs
  where source = 'boinc' union select * from archived_bugs
  where source = 'boinc') as all_boinc_bugs group by submitter
  order by count desc limit 5;
              submitter               | count
--------------------------------------+-------
 Sandro Tosi <matrixhasu@gmail.com>   |     8
 Thibaut VARENE <varenet@debian.org>  |     6
 Robert Millan <rmh@aybabtu.com>      |     6
 Martin Michlmayr <tbm@cyrius.com>    |     3
 Michael Ablassmeier <abi@grinser.de> |     2
(5 rows)

The small difference between the two lists is because UDD does not handle bugs that are assigned to multiple packages correctly yet.

Converting git-svn tag branches to real tags

Saturday, August 30th, 2008

Over the last few days I’ve converted some Subversion repositories used for Debian packaging to Git. None of these Subversion repositories contained upstream sources because of Subversion’s storage inefficiency. With Git I wanted to change that and also track the upstream sources in my repositories. To move a Git repository from a debian-only to debian+upstream layout I found zack’s recipe very helpful.

The actual conversion to Git was done with git-svn. I cloned the Subversion repositories with git-svn‘s --prefix=svn-import/ and --stdlayout options so that the trunk and all branches and tags were imported as remote branches with svn-import/ prepended. Then I created local branches of the previous Subversion branches and removed the remote remnants, for example:

git checkout -b debian/backports/etch svn-import/branches/etch-backports
git branch -d -r svn-import/branches/etch-backports

The Subversion tags are imported as svn-import/tags/<version> where <version> is the Debian version number. I don’t need branches for every version of my packages but I wanted to convert these tags to real Git tags but without losing the actual commit dates and messages. To achieve this I wrote this small script:

#!/bin/bash

for branch in `git branch -r`; do
    if [ `echo $branch | egrep "svn-import/tags/.+$"` ]; then
        version=`basename $branch`
        subject=`git log -1 --pretty=format:"%s" $branch`
        export GIT_COMMITTER_DATE=`git log -1 --pretty=format:"%ci" $branch`

        echo "Tag $version [Y/n]?"
        read yesno
        if [ -z $yesno ] || [ $yesno = "Y" ]; then
            git tag -s -f -m "$subject" "debian/$version" "$branch^"
            git branch -d -r $branch
        fi
    fi
done

For each remote branch that contains svn-import/tags/ it gets the version number, the commit message of the tag and exports GIT_COMMITTER_DATE (man git-tag) with the value of the date the version was tagged in Subversion and then asks you if it should tag the parent of the tag branch with the original commit date and message and remove the then unnecessary tag branch. The “safety measure” is there because people sometimes commit directly to Subversion tags (ugh!) and then "$branch^" would not be the commit you want to tag. To decide which Subversion tags are safe to tag with this script, gitk --all can be of great help.

P.S.: This is my first post on Planet Debian, so hello Planet! :-)

Kudos to the DebConf 8 videoteam!

Tuesday, August 12th, 2008

Thanks to the DebConf 8 videoteam I can watch all talks at DebConf 8 via live video streams from home. This is really a great service for all us who don’t attend DebConf! And it is much more fun than watching the recordings of the talks after DebConf has finished because questions/comments on IRC are relayed to the conference rooms. The only downside of the streams is the earpiercing tango between the sessions. :-)

DPL Election 2008

Sunday, March 30th, 2008

Today the voting period for the Debian Project Leader Election 2008 has started, and here is the ballot I've just submitted:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
d81e16a2-03b6-4340-84f2-51de89b8185e
[ 2 ] Choice 1: Steve McIntyre
[ 1 ] Choice 2: Raphael Hertzog
[ 3 ] Choice 3: Marc Brockschmidt
[ 4 ] Choice 4: None Of The Above
- - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH73cBft6HNdxCZCkRAmIgAJ49VGjuI6g+tIcgXhqMHXqE/kTNjQCcDqy5
oQSqQHJ5YCYtYE7y05mNdms=
=BwB2
-----END PGP SIGNATURE-----

This is the first election where I can actively participate since I became a Debian Developer on December 4th, 2007, and therefore I'm very interested in this year's DPL candidates and the election in general. I'm however a little bit disappointed because in my perception the candidates and their goals are less controversial than in the years before. It is also interesting to note that since 2004 this is the first election that has fewer candidates than the election in the preceding year (2008: #3, 2007: #8, 2006: #7, 2005: #6, 2004: #3).

Current mood: very happy!

Sunday, October 21st, 2007

Cause: “DAM Approval: Approved on 2007-10-21 by Joerg Jaspert (joerg)”. And this happened only 23 days after Front Desk checked the completeness of my report. I'm somehow impressed, thought this would take longer. Thanks to Joerg Jaspert!

Now I'm anxiously awaiting my account creation, let's see how long this takes...

How to find orphaned packages YOU should work on?

Thursday, October 11th, 2007

While being a Debian New Maintainer applicant, I decided to help the QA team by working on orphaned packages once I'm a Debian Developer. Currently there are 321 packages which are orphaned (O) or which a maintainer intents to adopt (ITA), see the packages overview for the Debian QA Group. Okay, so I've the choice to work on 321 different packages now, but which one should I choose? A tool which can help with this decision is wnpp-alert, it checks for installed packages that are up for adoption, orphaned or for which help is requested (RFH). It narrows down my selection to four orphaned packages, great! Now I want to sort these packages by their popularity (What's this?). For this task I've written a little script which uses the excellent grep-dctrl and ept-cache tools:

#!/bin/sh

MAINT=`(test -z "$1" && echo packages@qa.debian.org) || echo "$1"`

for x in `grep-status -F Maintainer "$MAINT" -n -s Package`; do
    ept-cache show $x | grep-dctrl '' -n -s Popcon,Package | paste -sd '\t';
done | sort -nr

It searches for installed packages that are maintained by the Debian QA Group and sorts them by their popcon score. If an argument is given to this script it will use it as search pattern for the Maintainer field instead of packages@qa.debian.org.

Note: You need to enable the popcon data provider for ept-cache for this script to work. See /usr/share/doc/ept-cache/README for details.