Issue Running MEGAN3.2 txt2ioapi

Hello Teachers,

I am using MEGAN3.2 to generate input files for CMAQ online coupling. I attempted to run the script run.txt2ioapi.csh from the ‘work’ directory, but both the terminal output and the log file were completely blank with no content.

To troubleshoot, I navigated to the MEGANv3.2_Dec_2021/src directory and manually set up the environment variables from the script in the terminal. Then, I ran ./txt2ioapi with the default test files, and it successfully produced three .ncf files.

After successfully running the test case, I modified the wrfout file path in the MEGAN32_Prep_Code_Jan_2022 directory to use my own wrfout file. This allowed me to generate the corresponding CT3.csv and OutputGridEF.csv files. However, when attempting the final step of converting the csv files to nc format, I encountered the following error (attached below). I am unsure whether this is due to the large size of my WRF simulation domain. I tried using ‘ulimit -s unlimited’, but the error persists.

I have attached the relevant files for further investigation. Any guidance on resolving this issue would be greatly appreciated.

CT3.csv (5.7 MB)
grid_ecotype.csv (1.6 MB)
grid_growth_form.csv (2.1 MB)
run.txt2ioapi.v32.csh (2.8 KB)

GRIDDESC:

Test data:

Error:

Hi Yan,

It looks like you’re missing one step. The growth_form and ecotype files go into the python preprocessor (EFP) that calculates a csv with emission factors based on the BVOC encyclopedia. That csv is then passed to the txt2ioapi program.

A user recently informed me that the link to the python code on the MEGAN website is broken. I’m not sure if it was intentionally taken down for critical updates or if there is some other issue. Here is the latest version of the EFP that I’m aware of.

I think running the EFP is one of the easier steps so you’re almost done, but let me know if you run into any issues.

-Jeff

Hi jeff,

I’m sorry that I failed to upload the files generated after Python processing because it is beyond 8 MB, which caused your misunderstanding. I got OutputGridEF.csv successfully and I put it with CT3.csv into MEGANv3.2_Dec_2021/Input/MAP path for final step running.

I see. Were you able to generate the CT3 nc file? I used your CT3.csv and GRIDDESC and the program completes, although there seems to be something strange about the southern boundary.

I tried to set setenv RUN_CANTYP T and setenv RUN_LDF T with others F it could complete successfully. However, when set setenv RUN_EFS T it occurs following error.

And according to the plot you provided I found that there is no value for southern Asia?



And I found that although it occurs error I got EFMAP.2019b.PRD.ncf and I use ncview to check it:

There are no values in S Asia for that canopy type. Others look as expected. Do your non-EF files look as expected? If so then something probably went wrong with the EFP step.

Hi jeff,

Thank you for your reply! Please allow me to ask you four questions.

  1. When setenv RUN_EFS T is set, although an error occurs during execution, I noticed that the variables have already been written into the file, along with the two lines: “Closing file EFMAPS” and “Closing EF IOAPI file” (as shown in Figure 1). At the same time, the EFMAP.ncf file was indeed generated in the MEGANv3.2_Dec_2021/Input/MAP directory.
    So, I am wondering whether this error actually does not affect the normal generation of the EFMAP.ncf file?

  2. I also found that when viewing LDF.ncf with ncview (Figure 3), the same issue occurred as when viewing EFMAP.ncf (Figure 2). The images appear as chaotic lines, unlike CT3.ncf, which has a clear outline of national borders (Figure 4).

  3. The third question is that when I checked CT3.ncf with ncview, I noticed that at the sixth time step (Figure 4), the image appeared normal (with valid values over India and Southeast Asia). This made me a bit confused—why does CT3.ncf has six time steps, and which part does CMAQ actually read? The last time step seems to be fine.

  4. By the way, I successfully ran CMAQ using these three files as inputs (the same files we discussed yesterday; I did not generate new ones today). However, when comparing the scenarios with and without biogenic emissions, the minimum and maximum ozone concentrations remained the same. Could this be because my WRF and CMAQ simulations only ran for 24 hours? Does that mean biogenic emissions didn’t have enough time to influence ozone levels?

Figure 1:

Figure 2:

Figure 3:

Figure 4:

  1. My guess is that the error is associated with the failure to create a file with reasonable contents.

  2. (and 3) CTF has the distribution for 6 canopy types. They’re not actually time steps. You’re looking at tropical, broad leaf, etc. If this file has canopy distributions that look reasonable but the LDF file does not then I would revisit the .inp files in your preprocessing steps. It looks like there might be an issue defining the domain in some of them.

  3. I would not bother running CMAQ with these files. Your emissions will look like the pattern you see when using ncview. That is obviously not realisitc.

Hi jeff,

Thank you so much for your help. I solved the problem and complete the program succuessfully. Could you help me check if these result files look normal?

CT3.ncf:

1

2

3

4

5

6

EFMAP.ncf:

LDF.ncf:

This looks more like what I would expect. Keep in mind that MEGAN 3.2 tends to overestimate monoterpene emissions (higher PM), and underestimate soil NO (lower ozone) with the default soil scheme.

Thank you! I’ll keep in mind.