You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
desi_tsnr_afterburner creates the top-level exposures-${SPECPROD}.(fits|csv) files. In addition, it can create the top-level tiles-${SPECPROD}.(fits|csv) files, however, desi_tiles_completeness can also do that.
Going from fuji/guadalupe to iron to jura, this afterburner process has been run in different ways each time, and each time, effectively "by hand". This should be standardized.
More detail on jura:
desi_tsnr_afterburner was run on each night in jura to create an exposure summary table for each night. This was done with jura/run/scripts/afterburner/code/generate_slurm_files.sh which used tsnr_template_script.slurm (same directory).
The per-night exposure tables were stacked with combine_tables.py (executed inside create_merged_tables.sh).
create_merged_tables.sh ran desi_tiles_completeness to create the tiles summary table.
The summary files were created in the run directory and then copied to the top-level specprod directory.
It is fine to run desi_tsnr_afterburner on individual nights and then assemble them. However the scripts needed to do so should be checked in, not left for detectives to have to find deep in the ${SPECPROD}/run directory.
Currently desi_tiles_completeness and desi_tsnr_afterburner --tile-completeness <tile-file> do the same thing, but with different code. This is confusing and could result in changes to one script not being applied to the other. There is also a subtle difference between Table.read(), used by desi_tiles_completeness and desispec.io.read_table(), used by desi_tsnr_afterburner. These differences should be eliminated, and possibly, desi_tiles_completeness should be eliminated entirely.
It should not be necessary to run a script twice to create a fits file and then a csv file. The same code should generate both files, always.
If the summary files must be created in the ${SPECPROD}/run directory, move them to the top-level instead of leaving a copy which could cause confusion to future detectives. This step should be documented and checked in as part of the suite of afterburner scripts.
The text was updated successfully, but these errors were encountered:
For context, this is related to issue #1724 to rewrite the tsnr_afterburner for cleaner data flow and better scaling. The messy history of how it has been run differently for each prod is because the method used by each previous production didn't keep up with the scale needed for a new prod, requiring some experimentation to find what could work given the existing tools.
And for completeness, desi_create_tilestable is yet another script for creating a tiles-SPECPROD.* file, completely independently of the TSNR code. That was on purpose to have something faster/lighterweight during jura while we were sorting out how to run tsnr at scale, but that does mean it is yet another place that does similar stuff. :(
desi_tsnr_afterburner
creates the top-levelexposures-${SPECPROD}.(fits|csv)
files. In addition, it can create the top-leveltiles-${SPECPROD}.(fits|csv)
files, however,desi_tiles_completeness
can also do that.Going from
fuji
/guadalupe
toiron
tojura
, this afterburner process has been run in different ways each time, and each time, effectively "by hand". This should be standardized.More detail on
jura
:desi_tsnr_afterburner
was run on each night injura
to create an exposure summary table for each night. This was done withjura/run/scripts/afterburner/code/generate_slurm_files.sh
which usedtsnr_template_script.slurm
(same directory).combine_tables.py
(executed insidecreate_merged_tables.sh
).create_merged_tables.sh
randesi_tiles_completeness
to create the tiles summary table.Options for
desi_tsnr_afterburner
injura
:Options for
desi_tiles_completeness
injura
:Recommendations:
desi_tsnr_afterburner
on individual nights and then assemble them. However the scripts needed to do so should be checked in, not left for detectives to have to find deep in the${SPECPROD}/run
directory.desi_tiles_completeness
anddesi_tsnr_afterburner --tile-completeness <tile-file>
do the same thing, but with different code. This is confusing and could result in changes to one script not being applied to the other. There is also a subtle difference betweenTable.read()
, used bydesi_tiles_completeness
anddesispec.io.read_table()
, used bydesi_tsnr_afterburner
. These differences should be eliminated, and possibly,desi_tiles_completeness
should be eliminated entirely.${SPECPROD}/run
directory, move them to the top-level instead of leaving a copy which could cause confusion to future detectives. This step should be documented and checked in as part of the suite of afterburner scripts.The text was updated successfully, but these errors were encountered: