The KCWI DRP: basic concepts

While most of the basic algorithms are inherited from the IDL KCWI pipeline (KDERP), the architecture of this pipeline is completely different.

Most of the underlying architecture is a consequence of using the Keck DRP Framework. This event-based framework implements a set of rules that connect events to processing code.

To illustrate this concept, we can use a simple event such as a new file on disk. The KCWI_DRP associates this event to a Python class called ingest_file. This means that the namespace contains a class or a function with this name. The processing code contained in the class or the function will then be applied to the file.

In more detail, if the code is a class, the _perform method of the class will be executed.

In our case, the ingest_file class looks at the header of the file and ingests it in its entirety. It then trigger further processing steps based on the image type.

Recipes and primitives

The original concept upon which this DRP is based is the separation of code in primitives and recipes. Primitives are simple pieces of code usually dedicated to a single operation. An example of a primitive would be subtract_bias, which takes a science frame and a master bias and performs the subtraction. Recipes are sequences of primitives, and they are usually associated with a specific image type. An example of a recipe is process_science which would contain calls to primitives such as subtract_overscan, apply_flat_field or apply_wavelength_calibration and so on.

The Keck DRP Framework doesn’t natively implement the concept of recipes, but it allows to specify a next event: the next event is an event that should automatically be triggered when the current event is finished. Using this, and linking individual events via the next event, we can easily build sequences of events which, for all intent and purposes, are the same as recipes.

These recipes are specified in a pipeline definition file, which can be found in kcwidrp/pipelines/kcwi_pipeline.py". This file contains an ``event_table which provides the link between events and processing code. For each entry, the third field is the next event.