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 :-)
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 .
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 :-)
- 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
- 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.
One convention is to use Y0, Y1, … to label fare classes from the highest fare (Y0) to the lowest fare (Yn). You can also use Y, B, M, H,… etc. An example of classes is below.
Example
Y0
Y1
Y2
Y3
Y4
Y5
If using cabins, it is reasonable to name the classes in consistent manner, but this is optional, and arbitrary class names are still allowed. All class names should still be unique, and cabin identifiers should be replicated identically for classes that share a cabin. Thus the list might look like this:
(F0, F)
(F1, F)
(Y0, Y)
(Y1, Y)
(Y2, Y)
(Y3, Y)
- 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.