Error in generating chemical lateral boundary conditions

[Ankan]

Dear Sir/Madam,
I have gone through the 'WRF-Chem 3.9.1.1 Emissions Guide'. Now, I am using mozbc to generate chemical lateral boundary conditions for WRF-Chem simulations (as described on page 38 of the emission guide). For that, I am using the MOZART-MOSAIC_4BINS input provided in the document from NCAR/ACD (the pdf is attached for your convenience). But I am getting the following error:
*** Error in `./mozbc': free(): invalid next size (normal): 0x00000000015c1ce0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x81489)[0x7f317a0d8489]
./mozbc[0x4052d2]
./mozbc[0x41cbcc]
./mozbc[0x422cff]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f317a0793d5]
./mozbc[0x4016e9]
======= Memory map: ========
00400000-00426000 r-xp 00000000 08:31 109183004 /data2/sunny/EMISSIONDATA/MOZBC/mozbc
00625000-00626000 r--p 00025000 08:31 109183004 /data2/sunny/EMISSIONDATA/MOZBC/mozbc
00626000-00627000 rw-p 00026000 08:31 109183004 /data2/sunny/EMISSIONDATA/MOZBC/mozbc
00627000-0063b000 rw-p 00000000 00:00 0
015b4000-015d5000 rw-p 00000000 00:00 0 [heap]
7f3170000000-7f3170021000 rw-p 00000000 00:00 0
7f3170021000-7f3174000000 ---p 00000000 00:00 0
7f3177e35000-7f3177e4c000 r-xp 00000000 fd:00 10580 /usr/lib64/libpthread-2.17.so
7f3177e4c000-7f317804b000 ---p 00017000 fd:00 10580 /usr/lib64/libpthread-2.17.so
7f317804b000-7f317804c000 r--p 00016000 fd:00 10580 /usr/lib64/libpthread-2.17.so
7f317804c000-7f317804d000 rw-p 00017000 fd:00 10580 /usr/lib64/libpthread-2.17.so
7f317804d000-7f3178051000 rw-p 00000000 00:00 0
7f3178051000-7f3178058000 r-xp 00000000 fd:00 10586 /usr/lib64/librt-2.17.so
7f3178058000-7f3178257000 ---p 00007000 fd:00 10586 /usr/lib64/librt-2.17.so
7f3178257000-7f3178258000 r--p 00006000 fd:00 10586 /usr/lib64/librt-2.17.so
7f3178258000-7f3178259000 rw-p 00007000 fd:00 10586 /usr/lib64/librt-2.17.so
7f3178259000-7f31789b1000 r-xp 00000000 fd:00 45542960 /opt/intel/compilers_and_libraries_2017.4.196/linux/mpi/intel64/lib/release_mt/libmpi.so.12.0
7f31789b1000-7f3178bb1000 ---p 00758000 fd:00 45542960 /opt/intel/compilers_and_libraries_2017.4.196/linux/mpi/intel64/lib/release_mt/libmpi.so.12.0
7f3178bb1000-7f3178bea000 rw-p 00758000 fd:00 45542960 /opt/intel/compilers_and_libraries_2017.4.196/linux/mpi/intel64/lib/release_mt/libmpi.so.12.0
7f3178bea000-7f3178f81000 rw-p 00000000 00:00 0
7f3178f81000-7f31790ff000 r-xp 00000000 fd:00 167307467 /opt/intel/compilers_and_libraries_2017.4.196/linux/mpi/intel64/lib/libmpifort.so.12.0
7f31790ff000-7f31792ff000 ---p 0017e000 fd:00 167307467 /opt/intel/compilers_and_libraries_2017.4.196/linux/mpi/intel64/lib/libmpifort.so.12.0
7f31792ff000-7f3179306000 rw-p 0017e000 fd:00 167307467 /opt/intel/compilers_and_libraries_2017.4.196/linux/mpi/intel64/lib/libmpifort.so.12.0
7f3179306000-7f317932a000 rw-p 00000000 00:00 0
7f317932a000-7f3179342000 r-xp 00000000 fd:00 217619979 /usr/local/gnuwrflib/zlib-128/zlibgnu/lib/libz.so.1.2.8
7f3179342000-7f3179541000 ---p 00018000 fd:00 217619979 /usr/local/gnuwrflib/zlib-128/zlibgnu/lib/libz.so.1.2.8
7f3179541000-7f3179542000 r--p 00017000 fd:00 217619979 /usr/local/gnuwrflib/zlib-128/zlibgnu/lib/libz.so.1.2.8
7f3179542000-7f3179543000 rw-p 00018000 fd:00 217619979 /usr/local/gnuwrflib/zlib-128/zlibgnu/lib/libz.so.1.2.8
7f3179543000-7f3179545000 r-xp 00000000 fd:00 10549 /usr/lib64/libdl-2.17.so
7f3179545000-7f3179745000 ---p 00002000 fd:00 10549 /usr/lib64/libdl-2.17.so
7f3179745000-7f3179746000 r--p 00002000 fd:00 10549 /usr/lib64/libdl-2.17.so
7f3179746000-7f3179747000 rw-p 00003000 fd:00 10549 /usr/lib64/libdl-2.17.so
7f3179747000-7f3179751000 r-xp 00000000 fd:00 90213880 /usr/local/gnuwrflib/szip-21/szipgnu/lib/libsz.so.2.0.0
7f3179751000-7f3179951000 ---p 0000a000 fd:00 90213880 /usr/local/gnuwrflib/szip-21/szipgnu/lib/libsz.so.2.0.0
7f3179951000-7f3179952000 r--p 0000a000 fd:00 90213880 /usr/local/gnuwrflib/szip-21/szipgnu/lib/libsz.so.2.0.0
7f3179952000-7f3179953000 rw-p 0000b000 fd:00 90213880 /usr/local/gnuwrflib/szip-21/szipgnu/lib/libsz.so.2.0.0
7f3179953000-7f317995b000 rw-p 00000000 00:00 0
7f317995b000-7f3179c29000 r-xp 00000000 fd:00 154782284 /usr/local/gnuwrflib/hdf5-1814/h5gnu/lib/libhdf5.so.9.0.0
7f3179c29000-7f3179e28000 ---p 002ce000 fd:00 154782284 /usr/local/gnuwrflib/hdf5-1814/h5gnu/lib/libhdf5.so.9.0.0
7f3179e28000-7f3179e2d000 r--p 002cd000 fd:00 154782284 /usr/local/gnuwrflib/hdf5-1814/h5gnu/lib/libhdf5.so.9.0.0
7f3179e2d000-7f3179e34000 rw-p 002d2000 fd:00 154782284 /usr/local/gnuwrflib/hdf5-1814/h5gnu/lib/libhdf5.so.9.0.0
7f3179e34000-7f3179e36000 rw-p 00000000 00:00 0
7f3179e36000-7f3179e54000 r-xp 00000000 fd:00 154782296 /usr/local/gnuwrflib/hdf5-1814/h5gnu/lib/libhdf5_hl.so.9.0.0
7f3179e54000-7f317a054000 ---p 0001e000 fd:00 154782296 /usr/local/gnuwrflib/hdf5-1814/h5gnu/lib/libhdf5_hl.so.9.0.0
7f317a054000-7f317a055000 r--p 0001e000 fd:00 154782296 /usr/local/gnuwrflib/hdf5-1814/h5gnu/lib/libhdf5_hl.so.9.0.0
7f317a055000-7f317a056000 rw-p 0001f000 fd:00 154782296 /usr/local/gnuwrflib/hdf5-1814/h5gnu/lib/libhdf5_hl.so.9.0.0
7f317a056000-7f317a057000 rw-p 00000000 00:00 0
7f317a057000-7f317a219000 r-xp 00000000 fd:00 10536 /usr/lib64/libc-2.17.so
Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0 0x7F317AB91697
#1 0x7F317AB91CDE
#2 0x7F317A08D27F
#3 0x7F317A08D207
#4 0x7F317A08E8F7
#5 0x7F317A0CFD26
#6 0x7F317A0D8488
#7 0x4052D1 in __utils_MOD_mapper at mo_utils.f90:291
#8 0x41CBCB in MAIN__ at main_bc_wrfchem.f90:134
./run_mozbc: line 1: 116370 Aborted (core dumped) ./mozbc < MOZART_MOSAIC_4_BINS.inp > MOZART_MOSAIC_4_BINS.out
Can you tell me why I am getting this error and how to solve it? I used the 'spc_map' option exactly as it is suggested in the document. I want to mention here that I used the EDGARv5_MOZART_dataset (from EDGAR v5.0 emissions inventory speciated for the MOZART chemical mechanism), which is a global emission dataset for the year 2015, for creating anthropogenic emission input files. There it is mentioned that "the dataset is also ready to use in the WRF-Chem atmospheric model with MOZART-MOSAIC options". That is why I am using the MOZART-MOSAIC option. I have used the 'edgarv5_MOZART_MOSAIC.inp' file (attached) given on their webpage after some modifications were made to the paths according to my case for generating anthropogenic emission input files (i.e.,'wrfchemi_d<nn>_<date>.nc'). I have checked after comparing these two input files and found that the 'emis_map' variable in 'edgarv5_MOZART_MOSAIC.inp' and 'spc_map' variable in 'MOZART-MOSAIC_4_BINS_INP.inp' (attached) are different. Should these have to be the same? I am really stuck with this issue. Since I am new to this model, any guidance would be greatly appreciated. For your convenience, I am also attaching the output file ('MOZART_MOSAIC_4_BINS._OUT.out'). Thank you.
With regards,
Ankan

 

[jordanschnell]

Hi Ankan,

First let's make sure you have enough memory. Are you running mozbc from the command line or submitting it as a job to an HPC cluster? If the former, try the latter. If the latter, try increasing the amount of memory available to the job.

Jordan

 

[Ankan]

Hello @jordanschnell ,
Thank you for your quick response. I am running mozbc by giving the following command:
./mozbc < MOZART_MOSAIC_4_BINS.inp > MOZART_MOSAIC_4_BINS.out
Does that mean the error is coming from memory alone?
With regards,
Ankan

 

[jordanschnell]

Hi @Ankan

It could be, do you have access to an HPC cluster so you can submit a job?

Jordan

 

[Ankan]

Hello @jordanschnell,
I don't have any access to an HPC cluster to submit a job. I am working on a server that has 32 processors. For your convenience, I am also attaching a screenshot of the memory information of my system after giving the 'free' command (see attached). Though I didn't try the 'mpirun np 28 ./mozbc MOZART_MOSAIC_4_BINS.inp > MOZART_MOSAIC_4_BINS.out' command because other utilities worked fine without it. Should it then work? Or does this MOZART-MOSAIC option only work when running in an HPC cluster? If it is so, then is there any other chemistry option you will suggest to use with the EDGARv5 MOZART dataset? Even though "emission map according to emiss_opt=10 used for MOZART-MOSAIC" is explicitly stated in the 'edgarv5_MOZART_MOSAIC.inp' file. Can you please guide me regarding this? That will be very helpful for me. Thank you for your time.
With regards,
Ankan

 

[jordanschnell]

Hi Ankan,

It's not that it will ONLY work with an HPC cluster, but it is likely going to be limiting you. Yes, you should try to run with all of the processors. Note though, that the actual WRF executable will be computationally expensive, and with that chemistry mechanism, your simulations will likely take a very long time to run unless your domain is very small. So even though you get passed this step, you may run into trouble down the road. That said, you may just need to pick a mechanism with fewer species (look at chem_opt in Registry/registry.chem). First try running with more processors.

Jordan

 

[Ankan]

Hello @jordanschnell,
I am trying with more processors by giving the following command:
mpirun np 28 ./mozbc MOZART_MOSAIC_4_BINS.inp > MOZART_MOSAIC_4_BINS.out
First, it throws the same error, but it is still running in the background. I have checked by giving the top command. For your convenience, I am attaching the screenshot. It is really confusing. I don't know if it will finally work or not. If it will work, then I will let you know. I want to mention here that before running this I tried the MOZCART option, and it worked successfully. So should I go with the MOZCART option then if I want to study aerosol-cloud-climate interaction? However, when I have gone through the tutorial presentation called 'Best Practices for Applying WRF-Chem 3.9.1.1', there it is mentioned that:
MOZART appropriate for simulations of pure gas-phase
MOZART-GOCART or MOZCART appropriate for simulations of months-years, simulations focused on trace gas chemistry
MOZART-MOSAIC appropriate for short-term simulations or aerosol-climate studies detailed analysis of trace gas and aerosol processes
I am interested in doing short-term simulations of two-three weeks for aerosol-cloud-climate interaction studies(i.e., third option). So, if I use MOZCART instead of MOZART-MOSAIC, should it cause any significant effect on my results?Can you please guide me in this regard. Thank you again.
With regards,
Ankan

 

[jordanschnell]

Hi Ankan,

Yes, you will need to use a chemical mechanism that includes aerosols in order to study aerosol interactions. That said, you are attempting to use one of the most computationally expensive mechanisms (# of tracers, # of chemical RXNs) with other computationally expensive options (i.e., direct and indirect aerosol feedback). You will likely have great difficulty getting answers in a reasonable amount of time with only 32 processors if the mozbc program is already taking awhile.

Regarding your command, you likely need a "-" in front of "np", i.e.,

mpirun -np 28 ./mozbc MOZART_MOSAIC_4_BINS.inp > MOZART_MOSAIC_4_BINS.out

Regarding your input file, continuing using MOZART_MOSAIC_4_BINS.inp for the mozbc input file, but please try to remove these lines as your .out file indicates it might be failing here:

'num_a01‐ >1.73e17*OC1+1.73e17*OC2+1.73e17*SOA+5.64e17*CB1+5.64e17*CB2+7.67e16*SO4+6.39 e16*NH4NO3+1.44e16*NH4+3.22e17*SA1+4.83e17*SA1+0.5*3.93e17*[DUST1];1.0',

'num_a02‐ >1.71e16*OC1+1.71e16*OC2+1.71e16*SOA+9.91e15*CB1+9.91e15*CB2+6.06e16*SO4+5.05 e16*NH4NO3+1.14e16*NH4+2.90e16*SA1+4.36e16*SA1+0.5*1.17e16*[DUST1]+0.24*1.17e16 *[DUST2];1.0',

'num_a03‐ >1.13e14*OC1+1.13e14*OC2+1.13e14*SOA+1.80e12*CB1+1.80e12*CB2+2.44e15*SO4+2.03 e15*NH4NO3+4.69e14*NH4+4.12e14*SA1+1.64e15*SA2+0.76*9.55e13*[DUST2]+9.55e13*[D UST3];1.0',

'num_a04‐ >4.09e10*OC1+4.09e10*OC2+4.09e10*SOA+3.42e07*CB1+3.42e07*CB2+3.25e12*SO4+2.71 e12*NH4NO3+6.12e11*NH4+7.60e13*SA3+1.49e12*[DUST4];1.0'

If it works after removing these lines, you'll need to go through them and look for the error.

Jordan

 

[Ankan]

Hello @jordanschnell,
Thank you for such a quick response. I want to mention here that when I tried with the previous input file (i.e., without removing the last four lines as you said) with 28 processors, mozbc failed to generate chemical lateral boundary conditions. I have been using
"mpirun -np 28 ./mozbc < MOZART_MOSAIC_4_BINS.inp > MOZART_MOSAIC_4_BINS.out" with a "-" in front of "np" (I made a typo here the last time). But, when I took your suggestion and modified the 'MOZART_MOSAIC_4_BINS.inp' after removing those last four lines, I think it worked. I have checked the 'MOZART_MOSAIC_4_BINS.out' and the following lines are printed at the end of this file:
successfully exited from module_wrfchem_lib ...
successfully exited from module_mozart_lib ...
bc_wrfchem completed successfully
That means the running of mozbc has been completed successfully. Right? If it is, then thanks again. That was really helpful for me. And I have just a few queries regarding MOZART. In the section 'Appendix B: Using MOZART with WRF-Chem' of WRF-Chem Version 3.9.1.1 User’s Guide (Page No : 63), it is mentioned that when setting up WRF-Chem to use MOZART, the user should select the FTUV photolysis option (phot_opt=3) in the namelist.input file. And for that, two additional input files for each domain are also needed– (1) exo_coldens_d<nn>.nc and (2) wrf_season_wes_usgs_d<nn>.nc (for the option gas_drydep_opt=1). The thing is, I have produced these additional input files by running 'exo_colden' and 'wesely' utilities but before running mozbc. Should it cause any significant differences? Or The generation of these two additional input files should be done after running mozbc? Another thing is, when I checked the Registry/registry.chem, I saw the following lines:
# ftuv exo column density files
rconfig character exo_coldens_inname namelist,chem max_domains "exo_coldens_<domain>" h "name of exo coldens infile" "" ""
# wesely seasonal veg cover for dry dep
rconfig character wes_seasonal_inname namelist,chem max_domains "wrf_season_wes_usgs_<domain>.nc" h "name of wesely seasonal infile" "" ""
That means I think I have to add 'exo_coldens_inname' and 'wes_seasonal_inname' variable in the 'namelist.inp' file like this:
exo_coldens_inname = "exo_coldens_d01.nc", "exo_coldens_d02.nc",
wes_seasonal_inname= "wrf_season_wes_usgs_d01.nc", "wrf_season_wes_usgs_d02.nc"
Right? So, my question is, where should I add these variables in the 'namelist.inp'? In '&chem' or in '&time_control'? Thank you in advance.
With regards,
Ankan

 

[jordanschnell]

Hi Ankan,

Yes, it looks like those lines in your mozbc input file were causing the issue. The program seems to have worked, however, now the number concentrations (i.e., the lines you removed) aren't being ingested so your simulations might return odd results. My suggestions would be to iteratively add back the lines until the error occurs again (make sure there are each on a single line), and then attempt to find out what is wrong with the line.

As for your additional questions.

The wesley and exo utilities are completely independent of the mozbc program and will not impact one another.
You can use either phot_opt =3 or 4 with MOZART, and yes, you would put those extra items in the chem namelist, but you don't need to as long as you follow the default naming convention in the registry (as you have done already).

Jordan

 

[Ankan]

Hello @jordanschnell,
Thank you for the clarification about the 'exo_colden' and 'wesley' utilities. But I didn't get your point about iteratively adding back the lines until the error occurred again. Did you mean that I have to add the lines one by one and then run mozbc and see if it throws any errors or not? If not then again add the next line and check again? Am I getting it correct? Can you please clarify it? Thank you for your time.
With regards,
Ankan

 

[jordanschnell]

Yes exactly. A 'brute force' debugging. My guess is either you had an accidental newline character or one of the species was not defined/referenced properly.

 

[Ankan]

Hello @jordanschnell,
Thank you for the suggestion. I will give it a try, then. However, I also tried running mozbc with CAM-chem model output files (here, 'camchem-20230121004408522074.nc'). No such error was thrown regarding the memory issue. But, after that, mozbc stopped and the following error was thrown:
init_mozart_lib: opened /data2/sunny/EMISSIONDATA/MOZBC/camchem-20230121004408522074.nc
checking wrf variable o3
len O3 = 2
chk_moz_vars: could not find O3_VMR_inst in /data2/sunny/EMISSIONDATA/MOZBC/camchem-20230121004408522074.nc
NetCDF: Variable not found
fail to process netCDF file...
Can you guide me as to why it is coming? I thought by looking at the error that it might be related to O3 and that if I removed O3 from the input file, it could solve the problem. But the same error was thrown again when the next species in the input file was read. I am attaching the input ('CAMchem_MOSAIC_4_BINS_INP.pdf') and output ('CAMchem_MOSAIC_4_BINS_OUT.pdf') files here. I have also checked the 'camchem-20230121004408522074.nc' file by giving the following command to see if O3 is there or not.
ncdump -v date,datesec camchem-20230121004408522074.nc > ncdump.log
But, I think that O3 is there. I am also attaching the 'ncdump.log' file for your convenience. Can you please help me understand the problem and how to solve it? That will be really helpful for me. So, any guidance on this will be greatly appreciated. Thank you again for your time.
With regards,
Ankan

 

[Ankan]

Hello @jordanschnell,
I solved the previous problem with CAM-chem model output files after adding moz_var_suffix = '' in the 'CAMchem_MOSAIC_4_BINS.inp' file. But, once again, I encountered a new problem, almost of the same kind, which is given below:
checking wrf variable oc_a01
len pom_a1 = 6
len soa1_a2 = 7
len soa1_a1 = 7
len soa2_a2 = 7
len soa2_a1 = 7
len soa3_a2 = 7
len soa3_a1 = 7
len soa4_a2 = 7
len soa4_a1 = 7
len soa5_a2 = 7
len = 0
chk_moz_vars: could not find in /data2/sunny/EMISSIONDATA/MOZBC/camchem-20230121004408522074.nc
NetCDF: Variable not found
fail to process netCDF file...
Can you tell me why the error is occurring? I am attaching both the modified input ('CAMchem_MOSAIC_4_BINS_INP.pdf') and output ('CAMchem_MOSAIC_4_BINS_OUT.pdf') files here for your convenience. Last time I solved the problem by looking at the 'mo_mozart_lib.f90' program. So, I am also attaching this program (here in pdf format) if it helps. I found these lines at the end of this Fortran program; maybe they will be useful for you. The lines are given below:
!---------------------------------------------------------------
! local variables
!---------------------------------------------------------------
integer :: i, n
integer :: vid
integer :: status
character(len=32) :: spcnam

do n = 1,nspec
write(*,*) 'checking wrf variable ',trim(wrf2mz_map%wrf_name)
do i = 1,wrf2mz_map%moz_cnt
spcnam = ' '
if( wrf2mz_map%moz_ext(i) ) then
spcnam = trim(wrf2mz_map%moz_names(i)) // trim(moz_var_suffix)
else
spcnam = trim(wrf2mz_map%moz_names(i))
end if
write(*,*) 'len ',trim(wrf2mz_map%moz_names(i)),' = ',len_trim(wrf2mz_map%moz_names(i))
status = nf_inq_varid( ncid, trim(spcnam), vid )
if( status /= nf_noerr ) then
write(*,*) 'chk_moz_vars: could not find ',spcnam,' in ',trim(filenm)
call handle_error( status )
end if
end do
end do

end subroutine chk_moz_vars

end module module_mozart_lib

(I don't know why an imoji came in the place of '( n )'. I tried many times to reedit it. But it didn't work. Please ignore it and replace it with 'first bracket no space n no space ending bracket'.)
I tried to decode it to solve the problem. But I am having problems understanding the program as I don't know Fortran. I checked the 'CAMchem_MOSAIC_4_BINS.out' once again. And I found the following lines:
mapper: spc_map = oc_a01->0.1216*pom_a1+0.9886*soa1_a2+0.1216*soa1_a1+0.9886*soa2_a2+0.1216*soa2_a1+0.9886*soa3_a2+0.1216*soa3_a1+0.9886*soa4_a2+0.1216*soa4_a1+0.9886*soa5_a2+0.1216*
mapper: spc_map = oc_a02->0.7618*pom_a1+0.0114*soa1_a2+0.7618*soa1_a1+0.0134*soa2_a2+0.7618*soa2_a1+0.0114*soa3_a2+0.7621*soa3_a1+0.0114*soa4_a2+0.7621*soa4_a1+0.0114*soa5_a2+ 0.7621
mapper: spc_map = oc_a03->0.1164*pom_a1+0.0*soa1_a2+0.1164*soa1_a1+0.0*soa2_a2+0.1164*soa2_a1+0.0*soa3_a2+0.1164*soa3_a1+0.0*soa4_a2+0.1164*soa4_a1+0.0*soa5_a2+ 0.1164*soa5_a1;1.e9
mapper: spc_map = oc_a04->0.0002*pom_a1+0.0*soa1_a2+0.0002*soa1_a1+0.0*soa2_a2+0.0002*soa2_a1+0.0*soa3_a2+0.0002*soa3_a1+0.0*soa4_a2+0.0002*soa4_a1+0.0*soa5_a2+ 0.0002*soa5_a1;1.e9
If you look closely, you will notice that mozbc cannot find 'soa5_a1' in 'oc_a01' and 'oc_a02', but it can find 'soa5_a1' in 'oc_a03' and 'oc_a04'. So, I removed the 'oc_a01' and 'oc_a02' lines and again checked. And it worked. That means, something is wrong with these two lines. But I don't know why that is so. Can you please have a look at it and guide me in this regard? That will be greatly appreciated. Thank you.
With regards,
Ankan

 

[Ankan]

Hello @jordanschnell,
Have you looked at the problem yet? I am waiting for your reply. Thank you in advance for taking the time to respond.
With regards,
Ankan

 

[jordanschnell]

Hi Ankan,

I can't tell because the are PDFs, but make sure all of your lines in the .inp file are a single line. Also check to make sure soa5_a1 is indeed in your input file.

 

[Ankan]

Hello @jordanschnell ,
I attached them as a pdf because the files could not be uploaded. Okay, I am attaching these in text format. Will that be okay? And, after looking at these and experimenting with the input file several times, I suspect that there may be a maximum limit on one line. That is why maybe 'soa5_a1 in 'oc_a01' and 'oc_a02' lines were not read, but were read in 'oc_a03' and 'oc_a04' lines. See here,
mapper: spc_map = oc_a02->0.7618*pom_a1+0.0114*soa1_a2+0.7618*soa1_a1+0.0134*soa2_a2+0.7618*soa2_a1+0.0114*soa3_a2+0.7621*soa3_a1+0.0114*soa4_a2+0.7621*soa4_a1+0.0114*soa5_a2+ 0.7621
mapper: spc_map = oc_a03->0.1164*pom_a1+0.0*soa1_a2+0.1164*soa1_a1+0.0*soa2_a2+0.1164*soa2_a1+0.0*soa3_a2+0.1164*soa3_a1+0.0*soa4_a2+0.1164*soa4_a1+0.0*soa5_a2+ 0.1164*soa5_a1;1.e9
Is it so? If it is, then is there any way to increase the character limit on one line? Can you please help me in this regard? Thank you again.
With regards,
Ankan

 

[jordanschnell]

Hi Ankan,

Can you please attach the other .f90 files - you may be right about a character limitation. Test this by removing a few decimal points from the oc_a01 and oc_a02 lines such that they are the same length as oc_a03 and oc_ao4. If it works, then we'll find the variable that needs a character increase.

Jordan

 

[Ankan]

Hello @jordanschnell,
Yes, of course. I am attaching the other '.f90' files. Also, I have tested by removing a few decimal points from the oc_a01 and oc_a02 lines by rounding them off such that they are the same length as oc_a03 and oc_ao4, and it worked. That means I think our guess is right: it might be due to some character limitation thing. Please find the attached '.f90' files. Thank you again for your time.
With regards,
Ankan

 

[Ankan]

Hello @jordanschnell,
I solved the problem by replacing the original.f90 files with the modified F90 files that I got from here: wrf-chem-mozbc - Google Groups. After that, I again recompiled the mozbc and then ran it without modifying anything in the input files, and it worked. I confirmed that the mozbc run had finished successfully. Thanks to my senior for that. And also, I want to thank you especially for interacting with me and guiding me constantly here by taking out your time from your busy schedule. Thank you again.
With regards,
Ankan