CAMx: changing MXPTSRC mid-run which requires recompiling executable

Other Software
1

What version of the other software are you using? CAMx v7.32

What steps have you taken to resolve this issue already?

I am currently running the December 2021 spin-up in preparation for the 2022 run using the EPA OSAP dataset that I have mentioned previously. However, I have encountered a series of errors like so:

ERROR in PNTPREP:
A parameter in the camx.prm is not sufficiently large.
Please change the value for parameter: MXPTSRC
It should be set to a value of at least: 995319

CAMx is stopping because of the error(s) described above

I first encountered this error when I started from 2021/12/22, where I had to change the default in /CAMx7v32/src.v7.32.Includes/camx.prm MXPTSRC=70000 (default) so that BCON_2022he_cb6r5ae7_HEMI.v55.20211222.camx >change to> MXPTSRC=914784

BCON_2022he_cb6r5ae7_HEMI.v55.20211228.camx >change to> MXPTSRC=925525

BCON_2022he_cb6r5ae7_HEMI.v55.20211229.camx >change to> MXPTSRC=995319

Each time I change MXPTSRCE I have to rebuild the CAMx executable, but it’s more an annoying pause rather than a fatal error. What concerns me is whether the restarted run will stay consistent in terms of mass conservation, or whether significant errors will creep in and cause sufficient deviations so that when I get to the first CAMx output checkpoint on 2022/01/01 my results may no longer be comparable to the EPA run in

https://epa-2022-modeling-platform.s3.amazonaws.com/CAMx_output_v2/2022001.12US2.35.2022he_cb6_HEMI_NH3Rscale0v2_AMD.epa.camx.avrg.grd01.nc

and

https://epa-2022-modeling-platform.s3.amazonaws.com/CAMx_output_v2/2022001.12US2.35.2022he_cb6_HEMI_NH3Rscale0v2_AMD.epa.camx.depn.grd01.nc

As a quick check I have looked at the BCON file sizes for 2021/12/22 here

https://epa-2022-modeling-platform.s3.amazonaws.com/bcon_v2/HEMI_CAMQ_12US2_CAMxBC_v2/BCON_2022he_cb6r5ae7_HEMI.v55.20211222.camx

and for 2021/12/29 here

https://epa-2022-modeling-platform.s3.amazonaws.com/bcon_v2/HEMI_CAMQ_12US2_CAMxBC_v2/BCON_2022he_cb6r5ae7_HEMI.v55.20211229.camx

and they are all 412MB. Can anyone confirm that I’m overthinking this, or would it be better to start over with the highest setting of MXPTSRC that I will encounter? The tradeoff is that the higher MXPTSRC is, the more memory CAMx will require, and the slower it will execute.

Please share your thoughts and experience!

2

Response from the CAMx developer:

There is no concern about inconsistencies in the concentrations because of the repeated compilations. If you want to avoid having to repeatedly update the MXPTSRC parameter and recompile you could analyze your point source files and determine the maximum number of point sources in any of the daily files. Then set the MXPTSRC parameter to this value. If your point source files are in NetCDF format you could just do “ncdump -h” on each file and look at the assignment of the COL dimension.

--gary–

3

Thank you @lizadams for passing on the response from Gary Wilson of Ramboll, that is reassuring confirmation that I’m still on the right track. The CAMx input data available from the EPA OSAP 2022 website is still in .camx and .bin format for the BCON, ICON, emis2d*, mrgpt* and ptsr* sets, so I was unable to examine them using ncdump -h. Even then, I was able to open only the ICON* and emis2d* files using Verdi but couldn’t find any option to check dimensions of variables included in both file types.

I had to restart my runs anyway as I started with the wrong Julian date for the spinup so there was a gap between the last day of 2021 and the first day of 2022, and may have to hardcode the Julian dates crossing from 2021 to 2022 since my existing CAMx runscript doesn’t provide for the transition when using the variable ${YESTERDAY}.

Thanks again!

4

This kind of date&time manipulation is made much easier by the use of standard M3Tools program timeshift:
given date and time ADATE and ATIME, and a time-shift TSTEP (typically 10000, for 1 hour), then you can get updated date& time BDATE and BTIME by

set foo = `timeshift ${ADATE}.${ATIME} ${TSTEP}
set BDATE = $foo:r
set BTIME = $foo:e

That should get rid of the need to special-case the end-of-year…

5

Thanks for that general solution. In this instance I found it easier to just hard code the interval from 31/Dec/2021 to 01/01/2022 just to get past the year change, and also to ensure I had a restart file for 31/Dec/2021 so I wouldn’t have to restart from 30/Dec/2021 in case the run got interrupted like during a local network-wide reboot we had recently.