3hourly as a basis for Aeronet colocation

[MichaelSchulzMETNO]

The basis for the IFS evaluation is so far daily. However, 3hourly data from Aeronet and IFS are available. Also - "daily averages" can be difficult and from different days eg near 180 degree longitude, in particula East Asia & Pacific, since data are on UTC. SDS-WAS was also using 3 hourly data for the dust evaluation, and the copernicus evaluation server as well.

In mid term it would be good to explore if co-location could be done on 3hourly basis.

[jgriesfeller]

Higher temporal resolution than daily Aeronet data (called all point data) has been used before (averaged to daily though). So the data is there.

According to https://github.com/metno/pyaerocom/blob/a483626c5e710e1dff63f68a2448a2c19ffc6400/pyaerocom/io/read_aeronet_sunv3.py#L28-L31

the all point data is also supported by the reader. But I don't think that anybody has ever used it since it's not mentioned in https://github.com/metno/pyaerocom/blob/a483626c5e710e1dff63f68a2448a2c19ffc6400/pyaerocom/io/read_aeronet_sunv3.py#L36-L37

I will try to use it and see if I get something out of it

[jgriesfeller]

Is there any 3hourly model data to compare btw?

[jgriesfeller]

I found some suitable 3hourly data within the aerocom data base (ECHAM6-SALSA_GLOFIR2) judging from this partial test, I would say that using 3hourly data should be possible in aeroval already

Unfortunately there are problems with in the Aeronet all points file's file encoding (not always compatible to Python's default file encoding of UTF-8). Examples:

(base) jang@pc5378:.../aerocom1/AEROCOM_OBSDATA$ file /lustre/storeA/project/aerocom/aerocom1/AEROCOM_OBSDATA/AeronetSunV3Lev2.0.AP/renamed/19930101_20211120_Aras_de_los_Olmos.lev20
/lustre/storeA/project/aerocom/aerocom1/AEROCOM_OBSDATA/AeronetSunV3Lev2.0.AP/renamed/19930101_20211120_Aras_de_los_Olmos.lev20: ISO-8859 text, with very long lines
(base) jang@pc5378:.../aerocom1/AEROCOM_OBSDATA$ file /lustre/storeA/project/aerocom/aerocom1/AEROCOM_OBSDATA/AeronetSunV3Lev2.0.AP/renamed/19930101_20211120_Apra_Harbor.lev20
/lustre/storeA/project/aerocom/aerocom1/AEROCOM_OBSDATA/AeronetSunV3Lev2.0.AP/renamed/19930101_20211120_Apra_Harbor.lev20: ASCII text, with very long lines

I will convert the aeronet files to proper utf-8 from within the download script.

am not sure, if the colocation is correct though

Trying to fix the aeronet reading first, then checking the results

[jgriesfeller]

the usage in general works, but I have not looked at the analysis yet to prove that the reading really produces 3hourly data and not something else. So keeping this open for now.

[github-actions[bot]]

This issue is stale because it has been open for 365 days with no activity. This issue will be closed in 14 days if no action is taken.

[lewisblake]

I wonder if we can close this now. Recently Thanos at KNMI did a little analysis / investigation into this and found that daily vs 3-hourly collocation did not seem to make a big difference in terms of the statistics nor scientific conclusions.

[MichaelSchulzMETNO]

I agree that Thanos showed that this is not a big problem. I think we should however look at Thanos results once together and store them somewhere for documenting the potential error.. What worries me still is that the daytime Aeronet observations in East Asia, near the date line, are split when using the same day definition across the globe. I think its worth devoting one session on analysing Thanos results.

[github-actions[bot]]

This issue is stale because it has been open for 365 days with no activity. This issue will be closed in 14 days if no action is taken.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.