# EXTRACT a certain domain from EDGAR\_v8.1 dataset

**URL:** <https://forum.cmascenter.org/t/extract-a-certain-domain-from-edgar-v8-1-dataset/5993>\
**Category:** Emissions Inventory\
**Created:** [September 10, 2025, 1:17pm UTC](https://forum.cmascenter.org/t/extract-a-certain-domain-from-edgar-v8-1-dataset/5993 "2025-09-10T13:17:15Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mason](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Mason](https://forum.cmascenter.org/u/Mason)\
**Post date:** [September 10, 2025, 1:17pm UTC](https://forum.cmascenter.org/t/extract-a-certain-domain-from-edgar-v8-1-dataset/5993/1 "2025-09-10T13:17:15Z")

</div>

Hello Everyone,

I want to extract a certain domain from Edgar.v8.1’s glob domain (1800\*3600).

So far, I have tried several approaches, including **CDO** , **NCO** , **Xarray** , and **NC.createDimension**. However, when I attempt to run smkinv, the process eventually fails with the following [error](https://forum.cmascenter.org/t/smoke-v4-8-process-meic-inventory-using-edgar-program/2783):

“Bad COL dimension for “fluxes” in “TMPFILE”

Has anyone successfully managed this type of extraction?

I also came across a related [discussion](https://forum.cmascenter.org/t/extract-emissions-from-edgar-htapv3-with-limited-geographical-domain-south-america/4610) regarding HTAP\_v3, and it is worth noting that **HTAP\_v3.1** provides the [HTAP Tool](https://edgar.jrc.ec.europa.eu/htap_tool) specifically for this purpose.

I greatly appreciate any insights or experiences.

Mason

---

<div class="post-metadata">

**Author:** ![huytran6583](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.cmascenter.org/huytran6583/32/3357_2.png) [@huytran6583](https://forum.cmascenter.org/u/huytran6583)\
**Post date:** [October 6, 2025, 3:50pm UTC](https://forum.cmascenter.org/t/extract-a-certain-domain-from-edgar-v8-1-dataset/5993/2 "2025-10-06T15:50:52Z")

</div>

Hi Mason,

Seems like you are wanting to process EDGAR HTAP v3 data for a custom domain with SMOKE. We have developed [instructions for processing HTAPv3 data with SMOKE](https://github.com/CEMPD/SMOKE/wiki/C.-Processing-HTAPv3-gridded-global-emission-inventories) in our SMOKE Wiki page. Please take a look and see if it could help. Your feedback is very welcome too.

Huy

---

<div class="post-metadata">

**Author:** ![Mason](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Mason](https://forum.cmascenter.org/u/Mason)\
**Post date:** [October 8, 2025, 6:10pm UTC](https://forum.cmascenter.org/t/extract-a-certain-domain-from-edgar-v8-1-dataset/5993/3 "2025-10-08T18:10:31Z")

</div>

Dear Huy,

Thank you very much for the instructions. I noticed that `HTAP_processing.py` uses the `sellonlatbox` command, and I implemented it in the same way (for a selected subset of the grid rather than the full domain).

This time `Smkinven` stopped with the [error](https://forum.cmascenter.org/t/smoke-using-htapv3-emission/5421) message: “`Bad NDIMS`”

My intention in creating a subset of HTAP or EDGAR was to reduce the size of the temporal output files when running all sectors and pollutants together (by using a single arinv list). Otherwise, the total size of the ATMP and ATSUP files reaches ~90 GB per day. However, I still encountered an error in `Grdmat` (by applying a single `arinv` list for all pollutants and sectors). The error did not occur for the parent domain, but it appeared for the inner domains. Below is the error for your review:

```auto
 Generating gridding matrix…
 "GRIDMASK" opened as OLD:READ-ONLY
 File name "/home/cmaq/smoke/data/ge_dat/EDGAR/GRIDMASK_EDGAR.ncf"
 File type GRDDED3
 Execution ID "????????????????"
 Grid name "LATLON_EDGAR0.1"
 Dimensions: 1800 rows, 3600 cols, 1 lays, 2 vbles
 NetCDF ID: 131072 opened as READONLY
 Time-independent data.

 "GRID_CRO_2D" opened as OLD:READ-ONLY
 File type GRDDED3
 Execution ID "mcip"
 Grid name "2025_d02"
 Dimensions: 108 rows, 108 cols, 1 lays, 6 vbles
 NetCDF ID: 196608 opened as READONLY
 Time-independent data.
 This file seems to use WMO-style "longitude" that violates ISO Standard 6709
 Number of coeffs 11664
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
libc.so.6 000014AE47A19520 Unknown Unknown Unknown
grdmat 0000000000416CB3 genlgmat 434 genlgmat.f
grdmat 0000000000423B43 grdmat 716 grdmat.f
grdmat 000000000040DA0D Unknown Unknown Unknown
libc.so.6 000014AE47A00D90 Unknown Unknown Unknown
libc.so.6 000014AE47A00E40 __libc_start_main Unknown Unknown
grdmat 000000000040D925 Unknown Unknown Unknown

```

I tried to resolve the issue but realized it might be due to the the way the inner `DO` loop is defined in `genlgmat.f`. The loop might iterate over `NCOEF` instead of `N`, which leads to out-of-bounds access of arrays, and causes `K` to exceed its allocated size.

Eventually, I decided to follow the @james.beidler [advice](https://forum.cmascenter.org/t/smoke-using-htapv3-emission/5421/8) and run sector by sector.

Mason