WRF-Chem/KPP build stops: “third body expected to be M” in CBM4 species file

[William.Hatheway]

Hi all — I’m seeing a reproducible WRF-Chem/KPP build stop that looks like an internal consistency issue in the CBM4 mechanism files


During a WRF-Chem build (`WRF_CHEM=1`, `WRF_KPP=1`), the `chem/KPP/compile_wkc` step iterates over mechanisms and exits with:

> `ERROR: variable name for third body in KPP species file is expected to be M, but was not found in cbm4 species file`

It occurs while processing:

chem/KPP/mechanisms/cbm4/cbm4.spc

Other mechanisms in the same tree define the third-body species explicitly as `M` (commonly annotated as “third body”), and the coupler logic appears to require that exact symbol name. In my case, CBM4’s `cbm4.spc` does not contain `M`, so the mechanism validation fails and the overall build stops—even if CBM4 is not the mechanism I intend to run.

This suggests a mismatch between:

* the WKC/KPP expectations (“third body must be named `M`”), and
* the shipped CBM4 species file content (missing/renamed third-body definition).

Can NCAR/WRF-Chem maintainers confirm whether:

1. `cbm4.spc` is supposed to include a third-body species named `M`, and/or
2. `compile_wkc` should be more flexible for CBM4 naming, and/or
3. this is a packaging/version regression specific to certain releases?

 

[William.Hatheway]

Hi all — I’m seeing a reproducible WRF-Chem/KPP build stop that looks like an internal consistency issue in the CBM4 mechanism files


During a WRF-Chem build (`WRF_CHEM=1`, `WRF_KPP=1`), the `chem/KPP/compile_wkc` step iterates over mechanisms and exits with:

> `ERROR: variable name for third body in KPP species file is expected to be M, but was not found in cbm4 species file`

It occurs while processing:

chem/KPP/mechanisms/cbm4/cbm4.spc

Other mechanisms in the same tree define the third-body species explicitly as `M` (commonly annotated as “third body”), and the coupler logic appears to require that exact symbol name. In my case, CBM4’s `cbm4.spc` does not contain `M`, so the mechanism validation fails and the overall build stops—even if CBM4 is not the mechanism I intend to run.

This suggests a mismatch between:

* the WKC/KPP expectations (“third body must be named `M`”), and
* the shipped CBM4 species file content (missing/renamed third-body definition).

Can NCAR/WRF-Chem maintainers confirm whether:

1. `cbm4.spc` is supposed to include a third-body species named `M`, and/or
2. `compile_wkc` should be more flexible for CBM4 naming, and/or
3. this is a packaging/version regression specific to certain releases?

Any update one this?

 

[William.Hatheway]

Hi all — I’m seeing a reproducible WRF-Chem/KPP build stop that looks like an internal consistency issue in the CBM4 mechanism files


During a WRF-Chem build (`WRF_CHEM=1`, `WRF_KPP=1`), the `chem/KPP/compile_wkc` step iterates over mechanisms and exits with:

> `ERROR: variable name for third body in KPP species file is expected to be M, but was not found in cbm4 species file`

It occurs while processing:

chem/KPP/mechanisms/cbm4/cbm4.spc

Other mechanisms in the same tree define the third-body species explicitly as `M` (commonly annotated as “third body”), and the coupler logic appears to require that exact symbol name. In my case, CBM4’s `cbm4.spc` does not contain `M`, so the mechanism validation fails and the overall build stops—even if CBM4 is not the mechanism I intend to run.

This suggests a mismatch between:

* the WKC/KPP expectations (“third body must be named `M`”), and
* the shipped CBM4 species file content (missing/renamed third-body definition).

Can NCAR/WRF-Chem maintainers confirm whether:

1. `cbm4.spc` is supposed to include a third-body species named `M`, and/or
2. `compile_wkc` should be more flexible for CBM4 naming, and/or
3. this is a packaging/version regression specific to certain releases?

seems to be a flex lib issue utilizing the flex apt package. If you install flex from source locally on your computer and point it to that it resolves the issue.

I would recommend for WRF 4.8.0 coming out soon that there be an optional instruction guide for installing flex package as part of the WRF library files.