MID Implementation

The implementation of the actual calculation for LOW and MID are different, however the two follow the same the basic structure of an API layer (see MID API docs page), validation, then calculation, using a look up table. The code is functional in nature, relying on pure functions which do not mutate state. The diagram below aims to give a view of this functional structure for the calculate and weighting endpoints.

Function flow when calling calculate endpoint

The flow is the same in general for the continuum and line calculations: each API path has its own function in the api module, and its own function in the service module. This service function is responsible for converting the correct input parameters into the calculation inputs. Then the same calculation function is used in all cases, with different inputs.

Function flow when calling weighting endpoint

See beam module implementation for the details of the lower level functions.

Module Structure

The Python modules can also been seen below.

MidCalculator class

The actual calculation displayed in the inner box above is a method on the MidCalculator class.

Note

Eventually this class will be simplified and made more functional.

The class MidCalculator has 2 public methods: calculate_sensitivity to get the array sensitivity in Jy for the given integration time, and calculate_integration_time to get the integration time required for the given sensitivity.

The MidCalculator constructor has a number of required parameters that define the observing configuration, target and weather. The rest default to None, in which case their values will be calculated automatically. The automatic values can be overriden by setting them here.

All parameters, internal variables and results that describe ‘physical’ measures are implemented as astropy Quantities to prevent mixups over units.