Error in MEGANv3.2 preprocessing

Hi all,
I am working on MEGAN32 preprocessing (compiled by gfortran, FFLAGS = -O3 -ffixed-line-length-132 -ffast-math -funroll-loops -m64 -fopenmp).
The data for LAI, Growth Form, Cantype, Ecotype, and Land Type are successfully processed. Although the “prepmegan4cmaq_.x” file could be successfully built for Nitrogen, Fertilizer, Arid, and Non-arid processes, I received two types of error when I tried to run the “prepmegan4cmaq_.x”.

One of the mentined errors is “STOP bio_emiss abort”, which generates a log file. I have attached an example of the log files related to the “STOP bio_emiss abort” error. The same problem was reported in the forum (An error occurred while running megan31 fert models:stop 'bio_emiss abort'). I applied the suggested solution, which included using CDO to regrid the input files. But the results have not changed.


           1          12 ./input/wrfout_d03_2012-06-01_00:00:00                                                                                                                                                                                                                                                                      ./input                                                                                                                                                                                                                                                                                                     
           1           1          96          81
 wrf_file: MAP_PROJ is not polar stereographic
 wrf_file: CEN_LON =    28.2622986    
 wrf_file: CEN_LAT =    40.7062798    
 wrf_file: STAND_LON =    24.0000000    
 wrf_file: TRUELAT1 =    30.0000000    
 wrf_file: TRUELAT2 =    60.0000000    
 wrf_file: DX =    4000.00000    
  
 proj_init: projection =  1
 proj_init: proj%hemi    =    1.00000000    
 proj_init: proj%rebydx  =    1592.50000    
 proj_init: proj%polei,j =   -38.4998322       1673.81335    
 proj_init: west-east,south-north =    96   81
  
 wrf domain corners
 --- ------ -------
 sw corner @ ( 25.890350    , 39.291683    )
 se corner @ ( 30.424133    , 39.109062    )
 ne corner @ ( 30.745300    , 42.067932    )
 nw corner @ ( 25.985229    , 42.260532    )
  
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 wrf_file: grid dimensions
 wrf_file: ids,ide,jds,jde
     1    96     1    81
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 month=           1
  
 Reading megan2 bio emiss file soil_nitrogen_mon01.nc
 megan2_bioemiss:  nlon_megan, nlat_megan =          288         192
 megan2_bioemiss: data_dx,dx,has_area_map =    104774.289       4000.00000     F
 megan2_bioemiss: file soil_nitrogen_mon01.nc has a new grid
  
 megan2_bioemiss: model lon limits =     25.89035034179688        30.74530029296875    
 megan2_bioemiss: model lat limits =     39.10906219482422        42.26053237915039    
  
 megan2_bioemiss: megan lon limits =    -180.0000000000000        178.7500000000000    
 megan2_bioemiss: megan lat limits =    -90.00000000000000        90.00000000000000    
  
 megan2_bioemiss: count of points <,> data min,max lat =            0
 xndx_megan =          165         170
 megan2_bioemiss: count of points < data min lat =            0
 megan2_bioemiss: count of points > data max lat =            0
 yndx_megan =          137         142

The other error is “Aborted (core dumped)” which generates an empty log file. However, some information is given in the terminal. For example:

Moreover, when I try running the same “*.x” file again and again, I get different types of the above-mentioned errors.

Thank you for any help in advance.
Reza

If you would re-compile, adding -g -fbacktrace to the compile flags, you should probably get the same error but you would get meaningful back-traces, i.e., what routine at what line number in which source-file. That extra information might wind up being helpful.

On the other hand: that the error is in nf_get_var_real_ does suggest that some array is being mis-dinensioned, and the attempt to read more data than the size of the array is what causes the seg-fault. Maybe the extra file+line-number info will help to diagnose which one, and hopefully why.

@cjcoats
Thank you for your reply. I will try your suggestion.

It sounds like something could be wrong with your soil .inp file, since that’s the one that’s used for those prepmegan*.x programs. Are the inputs (windowdefs, wrffile) the same for an inp file that works and the inp file that’s not working?

@willison.jeff
Yes, the inputs are the same.

update the subroutine “area_mapper.f90” as following

change
1416 real :: vtx_x(6)
1417 real :: vtx_y(6)
into
1416 real :: vtx_x(8)
1417 real :: vtx_y(8)

then re-compile and try again

@FengLiu
Thank you for your reply. But, unfortunately, it didn’t solve the problem. I got the same errors.

Sorry to hear that.

You may perform array bounds checking using right compiler option(s) to enable array bounds checking

@FengLiu
I agree with you. I think the problem originates from the compiler options. I used the above-mentioned compiler options during the installation. But, I noticed that I did not change the FFLAGS options in the Makefile under “MEGAN32_Prep_Code/”. I think the existing options (-O3 -Bstatic) do not belong to the gfortran compiler. I should find the equivalent of these options for the gfortran.

@FengLiu
Dear FengLiu,
Do you know the appropriate gfortran options for the preprocessing Makefile?

For compiler options, the I/O API ioapi/Makeinclude.* files are a good resource (Makeinclude.Linux2_x86_64gfort in the gfortran-compiler case):

  • MFLAGS is compiler-flags used by both C and Fortran compilers
  • OMPFLAGS is OpenMP-flags
  • FOPTFLAGS is the Fortran optimization (or debug) flags
  • ARCHLIB is the extra-libraries-needed flags

try to use

gfortran -O3 -Bstatic -fbounds-check

@FengLiu
Thank you for the suggestion. I tried that but I get this error:

So what happens in these lines of prepmegan4camq_fert.f90 -?

@cjcoats
These are the related lines:
Line11:
11

Line173:
173

Line736:
736

This would suggest that there is an argument-list error or an array-overflow in the call to handle_ncerr. Quite possibly, len_trim(message) is too long – note that netCDF’s handling of Fortran strings is not nearly so sophisticated nor robust as that of the I/O API…