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 triggers 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 into primitives and recipes. Primitives are simple pieces of code usually dedicated to a single operation. An example of a primitive would be SubtractBias, 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 SubtractOverscan, CorrectIllumination or FluxCalibrate and so on.

The Keck DRP Framework doesn’t natively implement the concept of recipes, but it implements a way 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 for this DRP 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.