DOCSEARCHbyAlgolia
Submit Docs

wtpy Documentation

repository·master·Indexed 23 days ago

https://github.com/wondertrader/wtpy

A Python 3 adaptation of the WonderTrader framework providing high-level interfaces to a high-performance C++ core for backtesting, data management, and live trading. It includes modules for CTA and HFT strategy definition, genetic algorithm optimization via WtCtaGAOptimizer, and high-performance data containers based on numpy ndarray (v0.9.9+). The framework features a monitoring service with HTTP and WebSocket interfaces, and tools for data downloading and contract selection.

Tokens
12.1K
Snippets
6
Records
73
Agent score
81%

What's inside wtpy

  1. Overview of the wtpy sub-framework modules

    master

    The wtpy sub-framework is the Python 3 adaptation for WonderTrader. It is organized into several functional modules:

    apps module

    Contains high-level analysis and optimization tools:

    • WtBtAnalyst.py: Backtesting analysis module that calculates metrics from backtest data and outputs to excel.
    • WtCtaOptimizer: CTA optimizer that uses multiprocessing for parallel backtesting and outputs statistics to csv.
    • WtHotPicker: Helper for domestic futures roll-over rules, supporting exchange website scraping or parsing datakit snapshot.csv files.

    wrapper module

    Provides interfaces for interacting with the C++ underlying core:

    • ContractLoader.py: Loads commodities.json and contracts.json via interfaces like CTP.
    • WtBtWrapper.py: Interface for the backtesting engine C++ core.
    • WtDtWrapper.py: Interface for the data component C++ core.
    • WtDtHelper.py: Converts user data into WonderTrader internal formats.
    • WtDtServoApi.py: Provides Python access to datakit stored data.
    • WtExecApi.py: Interface for the WtExecMon independent execution module.
    • WtWrapper.py: Interface for the live trading engine C++ core.
    • WtMQWrapper.py: Direct interface for the underlying WtMsgQue module.

    monitor module

    Contains built-in monitoring services providing Http and websocket connections:

    • DataMgr.py: Reads and caches portfolio data.
    • EventReceiver.py: Receives events forwarded by portfolios via udp ports.
    • PushSvr.py: Provides websocket services to the web.
    • WatchDog.py: Automatically schedules server-side processes.
    • WtBtMon.py: Manages backtesting.
    • WtMonSvr.py: Core monitoring service using flask to implement an http service interface.
    • static: Contains webui static files.

    Root Modules

    Contains entry components and strategy definitions:

    • WtCoreDefs.py: Defines the Python version of the strategy base class for users to override.
    • CodeHelper.py: Helper module for variety codes.
    • ContractMgr.py: Manages and queries contracts.json or stocks.json.
    • CtaContext.py, HftContext.py, SelContext.py: Define the execution environments (contexts) for CTA, HFT, and SEL strategies respectively.
    • ProductMgr.py: Queries contract and variety attributes in the Python environment.
    • SessionMgr.py: Manages trading session templates.
    • StrategyDefs.py: Defines base classes for CTA, HFT, and SEL strategies.
    • WtBtEngine.py, WtDtEngine.py, WtEngine.py: Wrapper modules for the Backtesting, Data, and Trading engines respectively.

  2. Manage trading via WtExecMon

    master
    Introduced in version 0.4.0, WtExecMon is an independent executor module that exports C interfaces. It decouples the strategy engine logic from the execution service, allowing it to function as a pure execution channel that can be integrated into other frameworks.

  3. High-performance data containers in wtpy v0.9.9

    master
    Starting from version 0.9.9, wtpy has replaced the previous DequeueRecord-based containers with new containers built directly on numpy memory using ndarray. This change significantly improves data read/write performance, with an estimated speedup of approximately 10x.

  4. Configure data loading with ExtDataLoder and ExtDataDumper

    master

    Version 0.8.0 introduced mechanisms for extending data handling:

    • ExtDataLoder: Allows both live trading and backtesting frameworks to load historical data via application-layer extension loaders.
    • ExtDataDumper: If registered with datakit, this mechanism allows real-time data to be dumped during market close operations.

    Refer to demos/test_dataexts for implementation examples.

  5. Install wtpy and prepare environment

    master
    To use the Python demos, ensure you have Python 3.6+ installed (32-bit or 64-bit). The wtpy framework will automatically select the appropriate underlying implementation based on your Python version. Install the wtpy sub-framework via pip (version >= v0.3.2).

  8. Configure and run live trading demos

    master

    Running a live trading demo requires a two-step process: first running the data component, then running the trading demo itself.

    Step 1: Run the Data Component

    1. Configure Parsers: In dtcfg.json, update the parsers array. For a simnow channel, provide your credentials and the contract codes using the format MarketCode.ContractCode (e.g., CFFEX.IF2005).
    2. Configure Writer: In dtcfg.json, set the writer object to define where data is stored (path), whether to save CSV logs (savelog), and if processing should be asynchronous (async).
    3. Configure Broadcaster: In dtcfg.json, set up the broadcaster to enable UDP broadcasting (currently supports memory block direct broadcasting).
    4. Execute: Run runDT.py.

    Step 2: Run the Trading Demo

    1. Configure config.json: Update the following sections in the demo's config.json:
      • data.store.path: Must match the path configured in the data component.
      • parsers: Configure the UDP receiver (host, port, and bport to match the data component's broadcaster).
      • traders: Configure the trading channel (module, host, port, credentials, and riskmon policies).
      • executers: Define execution units and bind them to a trader ID.
      • env: Set the engine type (cta or hft), session templates, and risk management (riskmon) parameters.
    2. Configure Auto Open/Close Policy: Update actpolicy.json to define the priority of actions (e.g., closeyestoday -> open -> closetoday) for specific instrument filters.
    3. Execute: Run run.py within the demo directory.

  9. Implement OptimizeNotifier for progress tracking

    master

    The OptimizeNotifier class allows you to subscribe to optimization lifecycle events via a message queue (WtMsgQue). This is useful for building dashboards or monitoring long-running optimization tasks.

    Events published:

    • OPT_START: Sent when optimization begins. Contains pgroups (total parameter groups).
    • OPT_STOP: Sent when optimization finishes. Contains pgroups and elapse (total elapsed time).
    • OPT_STATE: Sent periodically. Contains pgroups, done (completed tasks), progress (0.0-1.0), and elapse.

  10. Contract configuration data format

    master

    When WtCCLoader saves a file, it generates a JSON object containing contract details. Each contract entry includes:

    • name: The instrument identifier.
    • code: The instrument identifier (used as the primary key).
    • exchg: The exchange name (e.g., "OKEX", "BINANCE", "FTX").
    • extras: A dictionary containing exchange-specific metadata (e.g., baseCcy, quoteCcy, lever).
    • rules: Trading rules required by the engine:
      • session: Trading session (usually "ALLDAY").
      • holiday: Holiday information.
      • covermode: Position closing mode (0: open/close, 1: separate close today, 3: do not separate).
      • pricemode: Price order type (0: limit and market, 1: limit only, 2: market only).
      • category: Internal category ID (20: SPOT, 21: SWAP, 22: FUTURE, 23: MARGIN).
      • trademode: Trading mode (0: long/short, 1: long only, 2: long T+1).
      • pricetick: Minimum price increment.
      • lotstick: Minimum lot/size increment.
      • minlots: Minimum quantity per order.
      • volscale: Volume scale factor.

  11. Configure WtHotPicker switching algorithms

    master

    When calling pick_exchg_hots, you can specify the algorithm (alg) used to determine the main contract:

    • alg=0: Uses Open Interest (hold) to determine the main contract. This is the standard for most exchanges.
    • alg=1: Uses a specialized logic for CFFEX (China Financial Futures Exchange) that considers both volume and open interest, and includes a rule for forced switching on the third Wednesday of the month.

  12. Code format requirements for DHTushare

    master

    DHTushare uses a specific code format for mapping to TuShare. Standard codes should follow the pattern EXCHANGE.SYMBOL (e.g., SSE.600000 or SZSE.000001).

    For futures, the internal transCode function handles conversion from formats like DCE.a.2018 to the TuShare compatible format.

    Supported Exchange Mappings:

    • SSE $\rightarrow$ SH
    • SZSE $\rightarrow$ SZ
    • SHFE $\rightarrow$ SHF
    • CFFEX $\rightarrow$ CFX
    • CZCE $\rightarrow$ ZCE
    • GFEX $\rightarrow$ GFE