Colocation with climatological obsdata about pyaerocom HOT 8 CLOSED

@MichaelSchulzMETNO @jgriesfeller @AugustinMortier @hannasv feel free to comment or make suggestions. I would like to have a first version ready for v0.8.1 and will try to work on it a little in Abisko, if there is spare time.

from pyaerocom.

@jgliss In the aerocom-tools the time frame for climatology is static (years 2000 to 2010) across all data sets. I think there should just be one climatology, maybe with different time frames per data set.
The constraints are currently at least 30 days of data within these 10 years.
Regarding the year: a climatology consists of just one year of data (2999 in case of the aerocom-tools).
In IDL it is possible to compare different years (e.g. year 2008 model and year 2005 obs), but the time co-location is not time aware (uses just indexes)..

from pyaerocom.

@jgriesfeller thanks for the helpful input. I agree that a fixed climatology should be used by default but the code should be implemented such that the default range can be changed by the user. And as you suggest, I think it is good to set the time frame per dataset.

Regarding the constraints, maybe we can be a little stricter and require at least a certain number of points per year?

Regarding the year: The colocation routines in pyaerocom are flexible w.r.t. time and can also colocate multiple year model data with observations.

E.g. if the input model data is AOD from 2005 to 2015 then the the obsdata (e.g. AERONET) is extracted within this time interval and colocated. Now, if the climatological colocation is active, then the obsdata would be a single year. In this case I see currently 2 options:

1. Restrict the climatological colocation routine to single year model datasets.
2. Or colocate each year in a multi-year model dataset with the same climatology.

from pyaerocom.

I suggest we aim now for a new standard climatology 2005-2014 as default.
For comparison it would be nice to also have the old mean 2000-2009 as Jan described it.
Monthly data should be constructed for each station. For now we should stick to the old definition, that you need 30 days in 10 years within a given month. (weekly samples, eg deposition, rain concentration, count as 7 days). Time colocation should happen on month basis then (not years, days etc). Models can be compared both from individual years and based on model climatolgies. However, for now we aim to compare sinle years from the model, eg 2010 CTRL-AP3 to the observed climatologies.

from pyaerocom.

@MichaelSchulzMETNO @jgriesfeller Are we applying any further constraints regarding the sampled years?
For instance, if there is a station, that has only data within 2009-2011, but in each of the months enough data, so that the "30 days in 10 years within a given month" criterium is fulfilled: then we would get a climatological timeseries also for this station, even though the available years do not necessarily represent 2005-2015.

We could for instance,

• require that temporal coverage must cover at least 2006-2014?
• And / or a minimum number of years (e.g. 5) in which a given month needs to be sampled (i.e. in order to get month X in the climatological time series, we need data for that month in at least 5 of the 10 considered years.

I would opt for both, probably...

from pyaerocom.

Hi, I tested the new feature in a new experiment that evaluates all CTRL models I use for the optics study against climatologies (2005-2015) from the ground-based observations used in (PIII-optics2019). The results are available here:

https://aerocom-evaluation.met.no/overall.php?project=aerocom&exp=PIII-optics2019-CLIM

At a first glance, there are differences, but they don't seem to be too large. E.g. bias in surface scattering changes by up to 12% as compared with the results that were colocated using 2010 observations (e.g. CAM5-ATRAS). For absorption coeffs. and AOD the differences are less pronounced (up to ~5%).

from pyaerocom.

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.

from pyaerocom.

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

from pyaerocom.