U¶

class passengersim.rm.standard_systems.U[source]¶

Bases: RmSys

A standard RM system of type “U”.

This RM system uses path-level bid price controls with UDP optimization, along with EM untruncation and standard leg forecasting.

Parameters:

forecast_algorithm : {'additive_pickup', 'exp_smoothing', 'multiplicative_pickup'}, default 'additive_pickup'

Specifies which leg-level forecasting algorithm to use for generating leg demand forecasts. Options are ‘additive_pickup’, ‘exp_smoothing’, or ‘multiplicative_pickup’. The default is ‘additive_pickup’.

arrivals_per_time_slice : float, default 0.5

Specifies the expected number of customer arrivals per time slice used in the dynamic program optimization. This value affects the granularity of the discrete time approximation of the Poisson arrivals process; smaller values lead to finer granularity and a closer match to the theoretical continuous-time model, but increased computational time. Note that achieving a closer match to the continuous-time model may not always lead to better RM performance, as the actual customer arrival process may deviate from the Poisson assumption in practice (and in PassengerSim simulations). The default value is 0.5, which provides reasonably fast computational speed, while still capturing all forecast demand in the dynamic program.

em_initialization_method : {'default', 'pods'}, default 'default'

Specifies the initialization method for the EM untruncation algorithm. The ‘default’ method uses all available data at each iteration, while the ‘pods’ method uses only data from unclosed observations on the first EM iteration.

Notes

This RM system consists of the following actions executed in order:

1. EM Untruncation of Path Demands

   This step applies the EM algorithm to detruncate observed path sales into inferred true demand levels. It runs only once at the beginning of each sample day, and detruncates demand for all timeframes.

2. Standard Path Forecasting

   This step generates path-level demand forecasts using a standard class-based forecasting algorithm (additive pickup by default). It runs full computations to produce path forecasts for the entire booking horizon in one pass at the beginning of each sample day, and on later DCPs it simply moves a pointer forward through that array of forecasts to provide the correct forecast values at that time.

3. UDP Optimization

   Optimizes path-level bid prices using the Unbucketed Dynamic Program (UDP) algorithm. This step re-solves the dynamic program with updated displacement values based on actual sales and current forecasts only on the DCPs; however, it still updates the bid prices every day, using daily average bid price vectors taken from the most recent DP solution..

Initialize the RM system.

Parameters:

carrier : str

The carrier code for which this RM system is configured.

cfg : Config, optional

The top level configuration object for the simulation, which is also used to help initialize this system. For example, the collection of data collection points (DCPs) given as days prior to departure, is used for steps that have a frequency of “DCP” to identify which days to run.

**kwargs

Additional keyword arguments to configure the RM actions in this system.

Raises:

ValueError – If availability_control is not defined, or if no actions are defined, or if any provided keyword argument does not match any action’s configuration options.

Attributes

availability_control	This RM system uses bid price availability controls.
actions	List of RM actions (or action factories) to execute in this RM system.

availability_control : Literal['leg', 'cabin', 'bp', 'bp_loose', 'classless', None] = 'bp'¶

This RM system uses bid price availability controls.

actions : list[RmActionFactory | type[RmAction]] = [<passengersim.rm._common.RmActionFactory object>, <passengersim.rm._common.RmActionFactory object>, <passengersim.rm._common.RmActionFactory object>]¶

List of RM actions (or action factories) to execute in this RM system.

Each item in this list should be either an RmActionFactory instance, or an RmAction subclass. If an RmAction subclass is provided, its configure() class method will be called to create an RmActionFactory with no configurable parameters.

Subclasses of RmSys must set this class variable to a non-empty list of actions to be executed in order when this RM system runs.