Making New Network in AMET

In the AMET user guide, the most versatile data format is that for the SEARCH hourly data but I do not understand some headers and its value.
1.1. Do I need all columns for one variable (e.g. O3 - average, min, max, std, median and count here)?
1.2. What is the meaning of Flags[O3] value (A/v0/v1)?

2.1. I feel like other options are more straightforward (e.g. AQS_hourly, CASTNET_hourly, or NAPS hourly).
2.2. Why do you recommend SEARCH network?
2.3. What if I use AQS hourly, do I need AQS_CSN, AQS_daily, AQS_IMPROVE as well?
2.4. I have only few months data but do I need the whole year hourly data?
- making row for all year and making -999 or the model will match dates itself?

Other options (AQS_hourly)


I got this error because I have 4-6 digits for my parameter.
I checked it is working with 3 digits data.
How and where can I fix this problem?

I got the reason for this.
There is a limit in each column but I do not know how many letters I can put.
The error was coming from the unit in my case (e.g. particles/cm3)

Yes, you are correct. That error is indeed caused by the units loading in AMET. This is because there is a limit of 10 characters to the species unit length in AMET. So, your unit of “particles/cm3” exceeds the 10 character limit and causes an error.

The first part of this fix for this is fairly simple, which involves increasing the maximum length of the units variable definition in the AMET project_units database table. To do this, you’ll need to modify one AMET file. In the R_db_code directory, edit line 180 in the “AQ_add_aq2dbase.R” script from:

create_units_column ← paste(“alter table project_units add column “,units_to_add[i],” varchar(10);”,sep=“”)


create_units_column ← paste(“alter table project_units add column “,units_to_add[i],” varchar(50);”,sep=“”)

This will increase the maximum length of the units variable from 10 to 50. You could use a value greater or less than 50 if you’d like. It just needs to be large enough to allow all the characters for your units.

The second part of this fix is slightly more involved. Since you’ve already created and run this project, the units already exist in the “project_units” table in the AMET database with a character limit of 10. If you simply ran your code again with the change above, AMET would not recreate the units for that species with the new limit, as it just checks to see if the unit exists for that particular species and project, and if so, it does nothing. And, unfortunately, when you delete a project in AMET, it does not delete anything from the project_units table, which is an oversight on my part and something I will fix in the next version of AMET (more on this in a bit).

So, you’ll need to manually edit the species in the project_units table so that it has the increased character limit. To do this, you’ll need to log into MySQL directly and issue a few commands.

Generally, to log into the AMET database you can do:

mysql -h [AMET_HOSTNAME] -u [USERNAME] -p

You’ll be prompted for your AMET password for your USERNAME. Once you’ve logged into MySQL, go to the database that has your project:


Once in your database, you can now update the unit definition in the project_units table:

describe project_units;

This is show you the current species definitions in project_units. You’ll see that all the species have a definition of varchar(10). We want to change that to 50.

alter table project_units modify [species_name] varchar(50);

So, for example, to update the units definition for species PM_TOT, you would enter:

alter table project_units modify PM_TOT varchar(50);
describe project_units;

You would now see that PM_TOT has definition of varchar(50).

Once you’ve updated the units from the table, you can then run your script again (that was failing previously) and it should work correctly without the error about the data being too long.

I realize that I’ve provided a lot here. Hopefully everything is clear. If you have questions or run into any issues, please let me know, and I’d be happy to help you directly.