# MARS API Advice: Optimizing ENS PF Retrievals **URL:** \ **Category:** Computing at ECMWF\ **Created:** [6 November 2026 08:56 UTC](https://forum.ecmwf.int/t/mars-api-advice-optimizing-ens-pf-retrievals/15572 "2026-11-06T08:56:40Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Marek\_Kancir](https://forum.ecmwf.int/letter_avatar_proxy/v4/letter/m/d07c76/32.png) [@Marek\_Kancir](https://forum.ecmwf.int/u/Marek_Kancir)\ **Post date:** [6 November 2026 08:56 UTC](https://forum.ecmwf.int/t/mars-api-advice-optimizing-ens-pf-retrievals/15572/1 "2026-11-06T08:56:40Z")
We plan to retrieve large history of perturbed forecasts, our idea is to get history of forecasts starting in 2015, all 360 forecasting steps; based on availability about 14 – 20 variables and regular0.1/0.1 or 0.25/0.25 degree grid. We have tried couple of different request configurations based on [Guidelines for efficient MARS requests](https://confluence.ecmwf.int/spaces/UDOC/pages/77222294/ENS+Atmospheric+enfo+Perturbed+Forecast+pf+for+single+level+sfc+Guidelines+to+write+efficient+MARS+requests). We found out that basically every request (in its full form as below) is spilled over at least two tapes. We added area filter to limit download size but even with this filter requested parameters contain more than 100k fields. We suspect that large number of fields + MIR (resample / crop) contribute to long queue times. For example, retrieving one variable, one time, one date, 50 members, selecting subarea often takes between 30 – 40 minutes. Guidelines mention that we should not iterate through any of “Parameter”, “Number” and “Step” request parameters. **Typical MARS request structure** ``` { ``` "class": "od", "date": "2025-10-03", "expver": "1", "levtype": "sfc", "param": "167.128/168.128/246.228/247.228/169.128/177.128/29.228/134.128/146.128/147.128/159.128/165.128/166.128/228.128", "step": "0/.../360", # every step is explicitly named here "stream": "enfo", "time": "00:00:00", "type": "pf", "area": "51/-125/24/-64", "number": "1/to/50", "grid": "0.1/0.1", # We tried request with and without regridding to check if this step stalls the request but found out that for one variable it is approx. same ``` } ``` _Note: We are OK with workflow to regrid / crop data on our side if it yields faster downloads._ **Open Questions we have:** 1. **Grid & Area Regridding Strategy:** From a cluster-efficiency standpoint, do you recommend requesting `“grid”: “0.1/0.1”` and `“area”` directly via MARS, or is it significantly better for your queues if we pull raw global Octahedral Reduced Gaussian GRIB (O1280) data and perform spatial cropping/regridding locally using tools like earthkit-regrid or CDO? 2. **Optimal Splitting Unit:** When downloading multi-year time series, is looping by: - **date** (1 request = 1 full forecast date) the absolute best practice, or should we also chunk by **forecast steps** (e.g., splitting 0-144h and 150-360h into separate requests) to reduce queue penalties per request? - **area:** What is the queue penalty of requesting a sub-region versus the full global grid? Furthermore, is it advisable to split spatial areas to reduce field count, or does that cause redundant tape reads? - **parameters:** Is requesting all 14–20 parameters in a single combined request string the optimal strategy for physical tape layout? **Environment setup:** Python 3.13.14 ECMWF API python library 1.7.0 _Logged MARS package versions:_ MARS Client bundle version: 6.34.7.0 mir version: 1.23.9 odc version: 1.6.3 fdb version: 5.21.4 metkit version: 1.18.2 eckit version: 2.0.7 eccodes version: 2.47.1 **Request snippet** **```** from ecmwfapi import ECMWFService server = ECMWFService(“mars”) server.execute(req=my\_request, target=“path\_to\_grib”) **```** **Anonnymous user warning** This is probably unrelated but, when making request I see this response in the application logs: ``` “info”: { ``` "user_messages": { "anonymous": "You are accessing ECMWF data services as an anonymous user. For improved quality of service you should consider registering an account with ECMWF." } }, ``` ``` Looking on previous logs it seems I am logged in (I see greeting message) and using proper account with archive access. In my user home I have `.ecmwfapirc` file with contents: ``` { ``` "url" : "https://api.ecmwf.int/v1", "key" : , "email" : "[marek.goldstein@cez.cz](mailto:marek.goldstein@cez.cz)" ``` } ``` Any guidance on best practices for avoiding queue penalties while retrieving ENS data would be greatly appreciated.