Bi-Directional ammonia

Hy,
I am trying to run CMAQv5.4 with DDM using 2020 emissions data. The emissions dataset we have got from our collaborator does not include data for running the Ammonia Bi-directional tool in the CCTM script. My question is, can I use EQUATES ammonia bi-directional dataset for running CMAQ? My model domain is 12km and COLXROW is 442X365.

I tried to run one-month data using EQUATES data (please see the image below), but it seems CCTM crashed without giving any error. Without Ammonia tools turning on, the model runs fine.

Thanks
Rasel

Hi Rasel,

Can you search towards the bottom of each CTM_LOG file and also the I/O output files for an error? It is a bit strange that the model crashes without some kind of message. Also, are you saying that it runs when you set CTM_ABFLUX to FALSE? Is that what mean?

Are you able to run the 2018 Benchmark with DDM without issue? That case also has CTM_ABFLUX=TRUE by default.

Sergey

Hello Rasel,

two more questions in addition to those asked by @sergey:

  • which year(s) are you trying to run?
  • did you window the EQUATES EPIC files from their original 459x299 12US1 grid to your domain before attempting to use them? This might not be necessary, but we’re just trying to find potential reasons for the behavior you’re reporting.

@hogrefe.christian

Hello,

  • which year(s) are you trying to run?
  1. I am trying to run the CMAQ model for 2020. I am using emissions data provided by our collaborator. Their dataset does not have data to run ammonia bi directional flux. I was trying to use EQUATES 2019 bi-directional ammonia dataset as input in addition to the dataset I already have from my collaborators. Following are the dataset I am trying to use as input for ammonia bi-directional flux tool.
    (Also, please see attached script for details)

  • did you window the EQUATES EPIC files from their original 459x299 12US1 grid to your domain before attempting to use them? This might not be necessary, but we’re just trying to find potential reasons for the behavior you’re reporting.
  1. I did not window the EQUATES EPIC files from their original 459x299 12US1 grid to my domain (442X265) before attempting to use them. Not sure if the model crash fro this different grid column and rows or different grid name?

@sergey

Can you search towards the bottom of each CTM_LOG file and also the I/O output files for an error?

  • I have searched the log files and could not find an error. Please see some the log files I attached here.

Are you able to run the 2018 Benchmark with DDM without issue? That case also has CTM_ABFLUX=TRUE by default.

-I did not try to run 2018 Benchmark with DDM.

I am also attaching my script, slurm outputs. Please see the attached files.

CMAQ-5.4-amd078-464360.err.txt (29.6 KB)
CMAQ-5.4-amd078-464360.out.txt (1022.6 KB)
CTM_LOG_064.v54_DDM3D_gcc_AQF5X_20200201.txt (11.8 KB)
CTM_LOG_064.v54_DDM3D_gcc_AQF5X_20200201.txt (11.8 KB)
run_cctm_rasel.csh_sbatch.txt (41.2 KB)

Regards,
Rasel

Hi Rasel,

thanks for this additional information. I don’t know if this caused your crash, but the inputs required for the NH3 bi-direction model (prepared by EPIC through FEST-C) are time-specific, so using 2019 EQUATES NH3 bi-di files for running 2020 is not something you should attempt to do.

Aside from the temporal mismatch noted above, one of my colleagues also just pointed out to me that your target domain has more rows (365) than the EQUATES 12US1 domain (299), so even if the EQUATES files covered 2020, this would still not work because your domain is not a subset of the domain you’re providing the EPIC-generated NH3 bi-di inputs for.

(as a side note, I have not tested out if CMAQ windowing would work properly for these inputs if your domain was a subset of the 12US1 domain and if you didn’t deal with the temporal mismatch - it probably would, but personally I would probably window the inputs myself using m3wndw just to be sure).

If you want to include NH3 bi-di in your 2020 simulations, you probably will have to generate the required input files for your domain through FEST-C, unless someone in the community has already done this.

@hogrefe.christian

Thank you for your valuable suggestions. However, after looking into my one of my emission file and GRIDDESC file, I am seeing my number of rows 265. (Please see the image below).


In the CMAQ-5.4-amd078-464360.out.txt there are two errors reported from the debug flags one is an HDF error (Line 782 in H5.c) and another is a NetCDF error (line 189 in nf_control.F90). Additionally the file contains the warning:

Warning! HDF5 library version mismatched error
The HDF5 header files used to compile this application do not match
the version used by the HDF5 library to which this application is linked.
Data corruption or segmentation faults may occur if the application continues.
This can happen when an application was compiled by one version of HDF5 but
linked with a different version of static or shared HDF5 library.
You should recompile the application or check your shared library related
settings such as ‘LD_LIBRARY_PATH’.

The EQUATES EPIC data is compressed using the NetCDF 4 compression tools (zlib). If this is only input file that has been compressed, then this may explain the error when using the EQUATES Bidi NH3 inputs.

1 Like

@hogrefe.christian

Hy,
I am trying to run the CMAQ model for 2020. I am using emissions data provided by our collaborator. Their dataset does not have data to run ammonia bi directional flux. I was trying to use EQUATES 2019 bi-directional ammonia dataset as input in addition to the dataset I already have from my collaborators. Following are the dataset I am trying to use as input for ammonia bi-directional flux tool.

After running CMAQ I am having following errors:

Is this error could be due to mismatch of date? I am using 2020 emissions data. However, for bi-directional ammonia I am using 2019 Equates data.

Please see attached script and log file for more details.

Thanks
Rasel
run_cctm_rasel.csh_sbatch.txt (41.3 KB)

CTM_LOG_001.v54_DDM3D_gcc_AQF5X_20200201.txt (25.2 KB)

Yes. I’m glad that you were apparently able to resolved the HDF5 issues, but as noted in posts 5 and 6 above, you cannot use day-specific 2019 bi-di files from EPIC for simulating 2020.

If you think that the daily 2019 bi-di files containing soil information calculated by EPIC (which depend on 2019 fertilizer information and meteorology, among other factors considered by EPIC) might be appropriate for use in 2020, you could conceivably time-shift all the daily 2019 EPIC files to the corresponding day in 2020 before specifying them as input to a 2020 CMAQ run (you’d probably have to copy and then time-shift an adjacent day to handle February 29 in 2020).

The cleaner solution would be to to run EPIC through FEST-C for the year you are interested in simulating.

You could conceivably analyze the variables stored in the EQUATES EPIC files for different years to get a sense of their trends and interannual variabilty - e.g. compare the April 1 files for 2016 - 2019 - before deciding whether it might be appropriate to use the time-shifted 2019 files for 2020. It really depends on the intent and objectives of your study.

Thank you for your suggestion. It seems so far using m3tshift ioapi tool for shifting time works for me.

Regards,
Rasel

Time-shifting should certainly work on a “mechanical” level for getting over this error message, but whether it makes sense doing so is a different question. Only you can decide if it does, and analyzing the EQUATES EPIC files from different years may help you in reaching that decision.