Elegant users forum

I came across a way (e.g. user error) to corrupt an output file by accidentally
using the same file name for two output data:

&closed_orbit
output="%s.clo"
...
&end

&correct
mode = "orbit", method = "global",
trajectory_output = "%s.clo"
...
&end

The output file ending in .clo turned out to be a corrupted SDDS file.
The output of closed_orbit and correct are closed orbit data,
so I used the ".clo" suffix, which has been traditional for closed_orbit.
However the files in the commands &closed_orbit and &correct are
supposed to be different. What happened was that two headers were written
and binary data from two calculations was interleaved in the file.
I should have used a different suffix for the &correct trajectory_output.

This applies in general for all output files of the various elegant commands.

Louis Emery

The elegant manual recommends a different suffix for each
kinds of output. In the above case I didn't follow the recommendation
for trajectory_output (which I forgot):

http://www.aps.anl.gov/Accelerator_Syst ... ode23.html

trajectory_output -- The (incomplete) name of an SDDS file to which the trajectories or orbits
will be written. Recommended value: ``%s.traj'' or ``%s.orb''.

I should have used the orb suffix not the clo suffix.

Louis Emery

Louis,

The problem here is that, while SDDS does file locking, a process can't lock files against itself. So even though the closed orbit calculation locks the file, the orbit correction calculation is allowed to access it because it is part of the same process.

For now I think people just have to keep this limitation in mind. I'm not sure how we can solve it easily.

--Michael