The new-new scripts make this obsolete. If the user wants he can use his own code 
to submit the experiment or just use our submission code that calls qsub in the 
experiment's directory.

FYI, I have looked at the output of env, but there seems to be no 
variable that's useful for our purpose. Let's talk about it offline then :)

I can think of a few ways to work around the grid's limitations; it'll take too
long to elaborate on this in writing, so let's discuss this offline,

Closing this bug as there appears to be no workaround except the already existing 
wrapper experiment.sh

It seems that it is not possible to create a job, move the directory and 
submit it from a directory that doesn't contain the job file.

The only environment variable that might have been helpful SGE_O_WORKDIR 
only returns the current working directory when the job is submitted. I 
can't find a variable for the directory that contains the job file.

The directory in which the jobs should be executed can be set by adding 
"#$ -wd /path/to/dir" to the job file. However I couldn't figure out how 
to programmatically compute the path there or if that's even possible.

qsub has a bunch of working directory options; try "man 1 qsub" and search for
"working directory"; there are several leads.

Also, it sets a bunch of environment variables. Try running a job and looking at
the output of "env".

Unfortunately this does not work since the gkigrid seems to be in a 
special directory.

I also tried getting the absolute dirname, but

echo "$(dirname $(readlink -f $0))" returns 
/opt/sge6-2/spool/gkigridb/job_scripts

Do you have an idea how to solve this problem?

cd "$(dirname "$0")"

(The quotes are often not necessary, but it's better to use them in case there
are filenames with spaces or other unusual characters involved.)

This has been implemented. However currently gkigrid jobs can only be submitted 
while being in the directory that contains the job file. Is it possible to change 
into that directory with a bash command in the job file? If so, what would be the 
best way to do so?

It would be nice if the scripts generated by downward-experiments.py did not
include absolute paths, so that they can be run on machines with a different
filesystem layout than the one where the script was generated. (This is not just
a theoretical problem; it has already tripped me up multiple times.)

In general, I think it'd be a good idea if absolute paths were not stored
anywhere, i.e., they might be computed during a program invocation, but it'd be
good not to write them to a file to be used as a script or similar later.