Is there a reason why you didn’t use the precompiled executables that come with the NEI platform package but compiled your own? Incomparability? If you can still use them on your server, please use the precompiled laypoint program you downloaded with the platform package to see whether this addresses the issue or not.
I can’t use the precompiled model cause my system can only run large job with the program that compiled with gfortran while the pre-compile executables are compiled by the intel. I didn’t modify the source code but only switch to gfortran to compile the executable.
So none of months are running with your own Laypoint? Can you give a run for other months and let know?
I run July and August but none of them is successed. I am now thinking you probably correct that the executable I generated may be the problem. I tried the pre-compiled executable and some premerged outputs are generated (I can’t run the whole program with the precompiled executable but I test it for a while). However I can find the source code in the 2016 platform so I am not able to compile the executable by myself now. Do you happen to know where can I find the source codes for the executables? I am now using SMOKE v 4.8. I assume some source codes might be modified in the pre-compiled version.
I do not think we can confirm that it is a source code bug. Before we confirm, please go ahead run for other months to see any first day of month will run Laypoint successfully. If your domain covers the US, there should be at least one fire in first day of each month. If none of dates are running laypoint successfully, we can say that your executable has an issue.
Also, pleaser send me your Laypoint and grdmat log files as well as the header line of your METCRO3D file from MCIP for me to check the model domain consistency.
Thanks for suggestion. I run both July and August with my own generated executable from SMOKE v4.8 and the log files are attached. I use same script but with the pre-compiled executables from 2016 platform and successfully got some emis_mole_ptagfire3d* under premerged directory. Thus why I assume could be some bug in the origin source code from SMOKE v 4.8.
I used my own domain that covers whole US. The domain setting is like the following:
// global attributes:
:IOAPI_VERSION = “ioapi” ;
:EXEC_ID = "mcip " ;
:FTYPE = 1 ;
:CDATE = 2021201 ;
:CTIME = 201541 ;
:WDATE = 2021201 ;
:WTIME = 201541 ;
:SDATE = 2016183 ;
:STIME = 0 ;
:TSTEP = 10000 ;
:NTHIK = 1 ;
:NCOLS = 486 ;
:NROWS = 384 ;
:NLAYS = 30 ;
:NVARS = 16 ;
:GDTYP = 2 ;
:P_ALP = 33. ;
:P_BET = 45. ;
:P_GAM = -97. ;
:XCENT = -97. ;
:YCENT = 40. ;
:XORIG = -2916000. ;
:YORIG = -2304000. ;
:XCELL = 12000. ;
:YCELL = 12000. ;
:VGTYP = 7 ;
:VGTOP = 5000.f ;
:VGLVLS = 1.f, 0.996f, 0.99f, 0.983f, 0.97f, 0.954f, 0.934f, 0.909f, 0.88f, 0.845f, 0.807f, 0.765f, 0.719f, 0.672f, 0.622f, 0.571f, 0.507f, 0.444f, 0.38f, 0.324f, 0.273f, 0.228f, 0.188f, 0.152f, 0.121f, 0.093f, 0.069f, 0.048f, 0.029f, 0.014f, 0.f ;
:GDNAM = "US_12km_CROSS " ;
grdmat_ptagfire3D_2016fh_16j_US_12km.log.txt (18.2 KB)
laypoint_ptagfire3D_aug_2016fh_16j_20160801_US_12km.log.txt (21.8 KB)
I thought you were not able to run precompiled executables from 2016 platform on your server. If you were able run them successfully and generate the “emis_mole_ptagfire3d.*.ncf” files, there could be some incompatibility issues in SMOKE code with gfortran.
In this case, I would strongly suggest for you to keep using the precompiled executables from 2016 platform package. If that is still not an option, please recompile the 2016 platform original SMOKE source codes with the gfortran initialization flag “-finit-local-zero”. This flag option will initialize any un-initialized local variables to zero.
Thanks for your suggestion. I did add the flags in the make file when I compile smoke but still has the same error. Thus why I am thinking is it possible that I am not using same version of SMOKE as it provided in the 2016 platform. I am using v 4.8 and the precompiled version is v 4.7.
I have attached the precompiled SMOKE v4.8.1 with gfortran for you. Let me know whether this resolves your issue or not.
https://drive.google.com/drive/folders/1rHfjtmlB2iu5y7n3zC48Yno13IOyDr5t?usp=sharing
Thanks for your help. The model runs well using your pre-compiled executables and the emis_mole* outputs are generated.
That is a wonderful news! Glad to hear that this resolves the issue. Please let me know if you have any further issues.
I am still wandering why the executable I compiled is not working. Have you made any modification on the source code or the makefile (except the -finit-local-zero)?
Nope I did not make any update to the code. I think it may be related to your gfortran setup/version. This issue could happen when there is a bug in some versions of compiler and/or the way it got setup in your server. That is why I decided to compile the codes with my gfortran to see whether this is a bug in the code or not. This proves that it is not a bug.
BTW, you should add " -finit-local-zero" flag to Makeinclude file not to Makefile. Like this:
EFLAG = -finit-local-zero -ffixed-line-length-132 -fno-backslash # GNU Fortran
Oh I see. Thanks a lot for your help. Really appreciate your time.
Can you give another try with updating Makeinclude file with the following flag? Just curious whether “-finit-local-zero” flag was the fix for all this instead of compiler issue.
EFLAG = -finit-local-zero -ffixed-line-length-132 -fno-backslash # GNU Fortran
1 Like
Actually, I use the same EFLAG as you shown in last reply.
Hello @bbaek, I’ve run into a very similar string of errors trying to process the ptertac sector (replacement for ptegu sector) also for NEI 2016 v1. I’m using executables compiled on my machine mostly because we have GNU compilers (v9.3.1), but also because some folks at NYDEC let me know that smkinven reads in the ERTAC EGU data with a time shift, so they sent me a patch for that.
My errors followed a similar pattern through post #21, but adding
didn’t result in any change to the final error I’ve been facing, which remains related to the COSTCY file:
*******************************
* ERROR detected in logfile:
* /share/mzhang/jas983/emissions_data/nei_platform2016/v1/2016fh_16j/intermed/ptertac/logs/smkreport_ptertac_aug_2016fh_16j_temporal.log
*******************************
ERROR detected in Smkreport
ERROR: running QA & Smkreport for Temporal
Following this error to the smkreport_ptertac_aug_2016fh_16j_temporal.log I find:
File "COSTCY" opened for input on unit: 94
/share/mzhang/jas983/emissions_data/nei_platform2016/v1/ge_dat/costcy_2016v1_platform_30jan2019_v0.txt
Value for REPLABEL: 'ptertac_aug'
Value for REPLABEL: 'ptertac_aug'
Reading source data from inventory file...
Generating unique lists from inventory data...
Reading speciation matrices...
Reading supplemental temporal file...
*** ERROR ABORT in subroutine RDREPIN
Number of variables in TSUP file is not supported.
This error occurred while using the Linux2_x86_64gfort_mediumdbg version of both ioapi and smoke. However, I also downloaded the precompiled executables that you provided here:
but these resulted in a similar segmentation fault that I experienced with my own executables.
Thanks in advance for any advice you can provide!
Annual_ptertac_daily_summer_12US2_2016fh_16j_BM.csh (9.2 KB)
out_ptertac_summer.txt (10.5 KB)
rep_logs_ptertac_2016fh_16j_12OTC2_winter_level1.csv (10.5 KB)
smkreport_ptertac_aug_2016fh_16j_temporal.txt (15.9 KB)
temporal_ptertac_aug_2016fh_16j_20160801.txt (727.9 KB)
You’ll need to coordinate with someone familiar with running ERTAC emissions through SMOKE.
Based on the error message from Smkreport, there could be an inconsistency between the format of the temporal TSUP output file and the version of Smkreport program. TSUP format was updated a few years ago to enhance the quality of reports from Smkreport. To read this updated TSUP file properly, you also need an updated Smkreport program.
You will find out the version of SMOKE if you check the log files from Temporal and Smkreport programs. Ensure whether they are identical or not. If not, let me know which versions are used in both programs.