Carrier¶
- class passengersim.config.Carrier[source]¶
Bases:
NamedConfiguration for passengersim.Carrier object.
Attributes:
Name of the revenue management system used by this carrier.
Definition of the revenue management system used by this carrier.
Deprecated.
Used to select continuous pricing.
Where to record sales of continuous-prices products.
Record the highest closed fare class as open.
Controls quantization (rounding) for Continuous Pricing Example: If you set it to 5, the price will be rounded to the nearest $5
DEPRECATED - Controls upper and lower bounds for continuous pricing. Example: Y1 fare = $400, Y2 fare = $300 The difference is $100, and a 0.25 multiplier will set the lower bound for Y1 as $375 and the upper bound for Y2 as $325.
Controls upper bound for continuous pricing. Example: If the highest fare, Y0 = $400, then a 1.1 multiplier will allow CP to go up to $440.
Continuous pricing modifier scale factor.
Parameters to estimate customer price elasticity for CP - Defaults to being off - {'accuracy': 0.8, 'multiplier': 0.5} will guess 80% accurate and multiply the Frat5 value for leisure by 0.5 - Other algorithms to come in the future :-)
Limit the Continuous Pricing to local markets, or conecting markets Not currently implemented for every CP algorithm
Customer behavior models for Offer generation and optimization
Parameters for the contextual optimizer
Name of the FRAT5 curve to use.
Experimenting with different Frat5 curves by market
Store Q history for this carrier.
Named Load Factor curve.
Used for airline preference to give premium airlines a bump
Specifies ancillaries offered by the carrier, codes are ANC1 .
The ordering of cabins by quality, from best to worst.
A list of fare classes.
How to handle marking truncation of demand in timeframes.
How to prorate revenue to legs and buckets for connecting paths.
The number of samples to keep in the carrier's history buffers.
- rm_system : str¶
Name of the revenue management system used by this carrier.
If using a callback-style RM system, this can be given as a dict instead, in which case the name key is extracted and the rest of the dict is stored in rm_system_options. If a name key is not found, a validation error is raised.
- rm_system_options : dict[str, Any] | None¶
Definition of the revenue management system used by this carrier.
This can be used to declare parameters for this carrier’s RM system.
- control : str¶
Deprecated. No effect.
The control method for availability management is defined in the RM system, not in the carrier. This ensures that the correct control method is always used for each RM system.
- cp_algorithm : Literal['BP', 'CBC', 'OPT', 'CLASSLESS'] | None¶
Used to select continuous pricing.
The default is None, which means that continuous pricing is not used. If set to “BP”, then the continuous pricing is based on the bid price, i.e. the fare of the continuous priced product offered to the customer is equal to the bid price of the product, modified potentially by the cp_quantize and/or cp_bounds settings. If set to “CBC”, then the continuous price is set via a class-based continuous pricing algorithm, which adjusts the price of the continuous priced product based on the expected willingness to pay of the customer, as defined by the frat5 curve. In constrast to the “BP” algorithm, the “CBC” algorithm sets the price of the continuous priced product to be equal to the bid price plus the expected marginal revenue of the product,
OPT is an experimental algorithm that uses web-shopping (similar to Infare) and a choice model to try and improve the expected contribution of an airline’s offer(s)
- cp_record : Literal['highest_closed', 'lowest_open', 'nearest']¶
Where to record sales of continuous-prices products.
When a sale is made of a product that is offered at some modified price, (i.e., a continuous price), it can be recorded as a sale in the highest closed class, or in the lowest open class. This recording is relevant when forecasting demand in the various fare classes. If recording in the lowest open class, no other adjustments are made to the recording, as we are selling a fare class that is open. If recording in the highest closed, users should also review the cp_record_highest_closed_as_open setting, which controls whether the highest closed fare class is recorded as “open” in the history data, even though it otherwise would appear to be closed.
- cp_record_highest_closed_as_open : bool¶
Record the highest closed fare class as open.
When recording history data, by default the continuous pricing algorithm is ignored when getting closure status of each fare at the end of each DCP. If cp_algorithm is set to “highest_closed”, then the highest closed fare is actually being offered (with a modified price) to the customer, and the carrier may want to record this fare as open in the history data.
This setting has no effect on the actual continuous pricing algorithm at the time of making offers. It only affects the history data that is recorded. This setting is only used when cp_record is set to “highest_closed”, otherwise it has no effect.
- cp_quantize : int | None¶
Controls quantization (rounding) for Continuous Pricing Example: If you set it to 5, the price will be rounded to the nearest $5
- cp_bounds : float¶
DEPRECATED - Controls upper and lower bounds for continuous pricing. Example: Y1 fare = $400, Y2 fare = $300
The difference is $100, and a 0.25 multiplier will set the lower bound for Y1 as $375 and the upper bound for Y2 as $325
- cp_upper_bound : float¶
Controls upper bound for continuous pricing. Example: If the highest fare, Y0 = $400,
then a 1.1 multiplier will allow CP to go up to $440
- cp_scale : float¶
Continuous pricing modifier scale factor. This is used to scale the fare modifier when using CBC. Scales the fare modifier, which was computed using WTP
- cp_elasticity : dict | None¶
Parameters to estimate customer price elasticity for CP - Defaults to being off - {‘accuracy’: 0.8, ‘multiplier’: 0.5} will guess 80% accurate and multiply
the Frat5 value for leisure by 0.5
Other algorithms to come in the future :-)
- cp_markets : Literal['all', 'local', 'connect'] | None¶
Limit the Continuous Pricing to local markets, or conecting markets Not currently implemented for every CP algorithm
- customer_models : list[CustomerModel] | None¶
Customer behavior models for Offer generation and optimization
- contextual_optimizer : ContextualOptimizer | None¶
Parameters for the contextual optimizer
- frat5 : str | None¶
Name of the FRAT5 curve to use.
This is the default that will be applied if not found at a more detailed level. If not specified, the default frat5 from the carrier’s RM system is used.
- name : str¶
- frat5_map : dict | None¶
Experimenting with different Frat5 curves by market
- fare_adjustment_scale : float | None¶
- store_q_history : bool¶
Store Q history for this carrier.
This needs to be turned on Q forecasting RM systems. For other RM systems, the storage of this data is not needed, so it can be left off to save memory and processing time.
- load_factor_curve : Any | None¶
Named Load Factor curve. This is the default that will be applied if not found at a more detailed level
- brand_preference : float | None¶
Used for airline preference to give premium airlines a bump
- ancillaries : dict[str, float] | None¶
Specifies ancillaries offered by the carrier, codes are ANC1 .. ANC4
- cabin_ordering : list[CabinCode]¶
The ordering of cabins by quality, from best to worst.
The cabin code for each cabin must be a string of length 1.
For example, this could be [“F”, “J”, “W”, “Y”] for first, business, premium economy, and economy, in that order. We assume that any customer who books a fare for a given cabin will be satisfied by a seat in that specific cabin, or any better cabin. The default value of [“Y”] signals that there is only one cabin type in this carrier’s fleet.
This ordering must be comprehensive for all cabins on all this carrier’s legs. There cannot be a cabin on any leg operated by this carrier which does not appear on this list. The converse need not hold; it is acceptable for some legs to have fewer than the complete set of cabins.
- classes : list[str] | list[tuple[str, str]]¶
A list of fare classes.
This list can be a simple list of fare classes, or a list of 2-tuples where the first element is the fare class and the second element is the cabin.
If using the simple list format, the first character of each class must be one of the cabin codes defined in cabin_ordering. For example, if two cabins of types “F” and “Y” are possible, the fare classes could be:
Example
F0
F1
Y2
Y3
Y4
Y5
If using the 2-tuple format, the second item in each tuple must match one of the cabin codes, but the class names can be anything (including replicating the cabin names). For example:
(F, F)
(A, F)
(Y, Y)
(H, Y)
(L, Y)
(Q, Y)
Either way, all class names must be unique across the complete set of classes; you cannot have a class “X” associated with two different cabins.
- truncation_rule : Literal[1, 2, 3]¶
How to handle marking truncation of demand in timeframes.
If 1, then the demand is marked as truncated if the bucket or pathclass is closed at the DCP that is the beginning of the timeframe.
If 2, then the demand is marked as truncated if the bucket or pathclass is closed at the DCP that is the end of the timeframe.
If 3, then the demand is marked as truncated if the bucket or pathclass is closed at either of the DCPs that are at the beginning or the end of the timeframe.
- proration_rule : Literal['distance', 'sqrt_distance', 'off']¶
How to prorate revenue to legs and buckets for connecting paths.
If “distance”, then the revenue is prorated based on the relatives distance of the legs. So if the first leg is 100 miles and the second leg is 400 miles, then the first leg gets 20% of the revenue and the second leg gets 80%.
If “sqrt_distance”, then the revenue is prorated based on the relative square root of distance of the legs. So if the first leg is 100 miles and the second leg is 400 miles, then the first leg gets 1/3 of the revenue and the second leg gets 2/3.
If “off”, then no proration is done, and each leg and bucket gets the full revenue of the path. This will lead to double counting of revenue in legs, but is useful for some analyses.
- history_length : int¶
The number of samples to keep in the carrier’s history buffers.