Change request #1713
ctselect should write full paths into the outobs XML file
| Status: | New | Start date: | 02/24/2016 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assigned To: | - | % Done: | 0% | |
| Category: | - | |||
| Target version: | - | |||
| Duration: |
Description
At the moment, when running ctselect with an input observation container, the selected event files get written into the current working directory (which, however, can be steered by the hidden prefix parameter). The files of the selected event lists get written into the outobs XML file but only with the relative file paths:
<observation name="Crab Nebula" id="23523" instrument="HESS">
<parameter name="EventList" file="selected_events_023523.fits" />
<parameter name="EffectiveArea" file="/path/to/irfs/aeff_023523.fits.gz" />
<parameter name="PointSpreadFunction" file="/path/to/irfs/psf_king_023523.fits.gz" />
<parameter name="EnergyDispersion" file="/path/to/irfs/edisp_023523.fits.gz" />
<parameter name="Background" file="/path/to/irfs/bkgmodel.fits.gz" />
</observation>
Accordingly, when moving the
outobs XML file, it becomes unusable since the file “selected_events_023523.fits” doesn’t exist in the other directory.I therefore propose to change
ctselect to always write the full paths into the outobs XML file:... <parameter name="EventList" file="$PWD/selected_events_023523.fits" /> ...
I am however not sure if this change request kills another important use case I am not thinking of at the moment.
Another option might be to make the user aware of this in the documentation under “known issues” and state that one should use ctselect prefix=$PWD to get the full path written into the outobs XML file.
Recurrence
No recurrence.
History
#1
Updated by Knödlseder Jürgen about 8 years ago
This feature annoys me since some time. Neither solution is good. Absolute path names make it impossible to move the file, relative path names mean that the code needs to execute in the directory where the files reside (I’m even not sure that this depends on where the XML file resides).
There must be a more clever way how to deal with this, specifying for example somewhere a root directory from where the file paths are constructed (hence only only needs to repoint that root directory to another place). One could also image to have a script that deals with moving things, changing the file names accordingly.
#2
Updated by Mayer Michael about 8 years ago
I agree, while writing this issue, I realised that supporting both cases is very difficult.
In particular exchanging XML files and data between users is a use case we should keep in mind. I also can’t think of a good solution to handle this.
Having a root directory seems reasonable but complex. Having a script to copy and adapt the data doesn’t account for a user who intuitively does $ cp file1.fits ../file2.fits. Therefore, having files linked from the XML file is probably not ideal after all.
In the long run, having one FITS file including events and IRFs for all observations of interest might be more handy. So at the end, one would simply need a tool that extracts data and IRFs from a database and creates one single FITS file to work with.