2016 emission platform v1 adjust sectors

Hi all,

I am preparing 2016 emissions using 2016 EMP v1. I downloaded whole package directly from ftp://newftp.epa.gov/air/emismod/2016/v1/.

I have several questions:

  1. for all adj sectors runscripts, they always returned a similar error
    Annual_afdust_adj, Annual_othafdust_adj, and Monthly_othptdust_daily_adj
ERROR: Running xportfrac adjustments

or

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
mult.x             000000000044C402  Unknown               Unknown  Unknown
mult.x             000000000045ED03  Unknown               Unknown  Unknown
mult.x             000000000045E8ED  Unknown               Unknown  Unknown
mult.x             0000000000444401  Unknown               Unknown  Unknown
mult.x             000000000043BEFD  rdvars_                   218  rdvars.F
mult.x             000000000042F37F  rdgrdded_                 108  rdgrdded.f
mult.x             000000000040DE50  read3_                    311  read3.F
mult.x             0000000000403727  Unknown               Unknown  Unknown
mult.x             00000000004030E2  Unknown               Unknown  Unknown
libc.so.6          00002AAAAAFF33D5  Unknown               Unknown  Unknown
mult.x             0000000000403029  Unknown               Unknown  Unknown
ERROR: Running xportfrac adjustments

I’ve checked

limit stacksize unlimited

is stated in the beginning of all scripts

  1. in onroad sector, only onroad_ca_adj scripts are included:
Monthly_onroad_ca_adj_merge_12US1_2016fh_16j.csh  Monthly_onroad_ca_adj_RPH_12US1_2016fh_16j.csh  Monthly_onroad_ca_adj_RPV_12US1_2016fh_16j.csh
Monthly_onroad_ca_adj_RPD_12US1_2016fh_16j.csh    Monthly_onroad_ca_adj_RPP_12US1_2016fh_16j.csh

There is no onroad_ca, I am planning to use onroad_ca scripts from beta version, is there any changes for these scripts between v1 and beta?

  1. If I understand correctly, all adj scripts are used to adjust land use and MET; therefore, I have to run the scripts without adj and then run the scripts with adj.

but from beta TSD the summary of 12US emissions

I do see afdust_adj, but not othafdust_adj and othptdust_adj, so in the table does othafdust represent othafdust_adj, or this did not run through othafdust_adj?

Any suggestion will be heplful.
Cheers,

Joey

1 Like

Hi Joey,
This question was missed by reviewers because there wasn’t a category assigned to it. I’ve added SMOKE and NEI Modeling Platform as the category.
Were you able to get past this error?

Liz

Liz,

Thanks for correcting the category.

I’ve fixed issue 1, but still not know what to do for issue 2 and 3.

Best,

Joey

We see that you have resolved #1. For the other two questions:

  1. The onroad_ca sector does not need to be run. We’ve never included onroad_ca scripts in the packages so are unsure where you got those.

  2. That table
    does represent othafdust_adj and othptdust_adj rather than othafdust and othptdust.

Alison

Alison,

Thank you!

For the onroad_ca issue:

from 2016 v1 there are:

[jhuang@ncaqc2017 onroad]$ ll *ca*12US1*
-rwxrwxr-x 1 jhuang hpc 8151 Nov 22 19:56 Monthly_onroad_ca_adj_merge_12US1_2016fh_16j.csh
-rwxrwxr-x 1 jhuang hpc 8310 Nov  4 14:50 Monthly_onroad_ca_adj_RPD_12US1_2016fh_16j.csh
-rwxrwxr-x 1 jhuang hpc 8581 Nov  4 14:50 Monthly_onroad_ca_adj_RPH_12US1_2016fh_16j.csh
-rwxrwxr-x 1 jhuang hpc 8544 Nov  4 14:50 Monthly_onroad_ca_adj_RPP_12US1_2016fh_16j.csh
-rwxrwxr-x 1 jhuang hpc 8513 Nov  4 14:50 Monthly_onroad_ca_adj_RPV_12US1_2016fh_16j.csh

However, from beta package

[jhuang@ncaqc2017 onroad]$ ll *ca*
-rwxr-xr-x 1 jhuang hpc 7983 Oct 28 15:54 Monthly_onroad_ca_adj_merge_12US1_2016ff_16j.csh
-rwxr-xr-x 1 jhuang hpc 3223 Oct 28 15:54 Monthly_onroad_ca_adj_merge_12US1_2016ff_16j_part2_combine.csh
-rwxr-xr-x 1 jhuang hpc 8152 Oct 28 15:54 Monthly_onroad_ca_adj_RPD_12US1_2016ff_16j.csh
-rwxr-xr-x 1 jhuang hpc 8357 Oct 28 15:54 Monthly_onroad_ca_adj_RPH_12US1_2016ff_16j.csh
-rwxr-xr-x 1 jhuang hpc 8367 Oct 28 15:54 Monthly_onroad_ca_adj_RPP_12US1_2016ff_16j.csh
-rwxr-xr-x 1 jhuang hpc 8336 Oct 28 15:54 Monthly_onroad_ca_adj_RPV_12US1_2016ff_16j.csh

there is a part2 script in beta version.

Sorry for the confusion.

Best,

Joey

Hi Joey, we think you are talking about onroad_ca_adj. So your question is: why is there no part 2 (combine) script in v1?

The short answer is: starting with v1 platform, the part 2 script is no longer needed for onroad or onroad_ca_adj.

A bit more info from the README for the 2016v1 platform:

  • Also for onroad and onroad_ca_adj, MOVES2014b supports CB6-CMAQ speciation, and so the EFs

for this platform include the extra species which are part of that mechanism (SOAALK and XYLMN).

Therefore, the CB6-CMAQ conversion step is no longer needed for onroad and onroad_ca_adj.

It is still required for onroad_mex.

Hello Joey,

I have the same error that you have had for problem 1 – do you remember what your solution was for this?

Thanks,
Anastasia

@huangj1311 Hey Joey, some of folks are having the same issue of running xportfrac tool for adjustment. Can you share how you were able to pass this issue?

@asmontgomery

I barely remembered what I did, the main issue was when it reads afdust output, and there is some incorrect variables in EMF runscripts or malfunctions of EMF runscripts. Please give me a week to take a look this, I don’t have 2016 EMP ready on our cluster at this point, I will try re-run afdust and adj this and next week to look into the issue.

Thank you so so much! – I’m going to look into the scripts again to double check, I’ll let you know if I see the error there!

could you please send me the header of your emis_mole_afdust_20160101_12US2_cmaq_cb6_2016fh_16j

use

ncdump emis_mole_afdust_20160101_12US2_cmaq_cb6_2016fh_16j.ncf | more

and copy the ROW COL information?

and also please let me know the domain you are working on ROW and COL number.

Hello, I’m doing a 4 km CONUS run so I have:

ROW = 726 ;
COL = 1155 ;

However, this is the same as my domain I am working on. Here is my GRIDDESC file:

'LAM_40N97W'
  2        33.000        45.000       -97.000       -97.000        40.000
' '
'CONUS4K_d02'
'LAM_40N97W'  -2292000.000  -1584000.000      4000.000      4000.000 1155 726   1

Is that the error? Or did I misunderstand the question you’ve just asked?

The first thing is to double check your domain is consistent with you xportfrac file.

If they are, in you case, you might want to check do you have enough memory for 4km CONUS?

Carlie is the expert for this.

@cjcoats, for this large file, can pre-compiled SMOKE handle the size via pre-compiled IOAPI?

I will also dig into any other potential errors through next following two weeks.

1 Like

Are any of the arrays larger than 2 GB (e.g., 500x1000 grids has size 50010004 bytes = 2GB)? If so, it needs one of the “medium memory model” versions of both the I/O API and then the program-build.

Even so, I think that should cause an error when you use the array, rather than when you read it. – Carlie

Thank you again for you help, @huangj1311 and @cjcoats

I don’t believe this to be a memory error, but I think you may have illuminated the error …

netcdf xportfrac.8vars.beld3.4kmgrid.CONUS4K {
dimensions:
TSTEP = 1 ;
DATE-TIME = 2 ;
LAY = 1 ;
VAR = 10 ;
ROW = 837 ;
COL = 1237 ;

which is obviously different than my grid (1155 x 726)… I think this might be my error. I’m running a nested run because of another workaround, and I think I created the xport frac file for original 4 km domain I tried to create. Just to confirm, the xportfrac file should be on my CONUS4K_d02 grid – correct?

gives 1155x726x4 is about 3.3 GB, so this does need medium memory model for the processing, once it gets that far. Q: did the allocation for this-size array silently fail, giving rise to the observed error?

Hello,

Thank you for your help – I subverted the need for a medium memory model (as I don’t have the compiled SMOKE with that build so I’m wary that I might need it in the future) by adding in IOAPI_OFFSET_64 = “Y” in the runscript.

I also recreated the xportfrac file.

I believe my error with problem 1 has been addressed with these two fixes.