Ok, I dont know about the values from Qp1, but there might be a bug as
you suggested. Hopefully Patrick will be able to confirm this. The
values from Qp2 looks more reasonable (0.3% obs error and 9% smoothing).
As for the averaging kernels they underline just as you say that using
VMR retrieval might not be the best method to do the retrieval, since
they look strange in VMR units, but if you want to present your data in
VMR, the converted averaging kernels are truly the relevant once.
If you for instance want to compare your data to satellite data
presented in vmr you need to convolve the satellite data with the
converted ("strange") AVKs to get the correct results.
regards
Ole Martin
On 22/06/11 16:09, Rene Bleisch wrote:
> Hi Ole Martin
> answers below
>
> Regards
> René
>
> On 22.06.2011 15:10, Ole Martin Christensen wrote:
>> The error analysis in Qpack to should now be consistent so that if the
>> calculations are preformed in logrel or rel the errors(all of them)
>> should come out relative units. To convert to vmr the qp2_rel2vmr is used.
>>
>> Im not sure about the error quantities in Qp1. But it very well might be
>> as you suggest that the observation error comes out in absolute units in
>> Qp1. What are the values for smoothing and observation error in Qp1 and
>> Qp2 before and after converting?
>>
>>
> One example of the errors at surface altitude (xa= 0.0101 in vmr units),
> all values are as delivered by Qpack1/2:
>
> Qp1: e_obs = 3.5972e-05, e_smo = 0.0902
> Qp2: eo = 0.0034, es = 0.0908
> Qp2(converted) eo = 3.4277e-05, es = 9.6232e-04
>> You write that your apriori profile is a vector of ones for the vmr
>> case, wouldn't this imply a huge amount of water (1 000 000 ppm?). Could
>> you attach your two Q-files with your response so I can have a look at them?
>>
> I didn't do testings for the 'vmr' case, I just had a look on the Qpack1
> routines. The error calculations are done in qpcls.m L776ff. unitfac
> comes from qp_x2X.m, where it is defined as ones(length (profile)) for
> the absolute (unit='vmr') case, resp. xa for the 'logrel' case.
>
> In summary, the (unitfac*unitfac') correction term doesn't do anything
> in 'vmr' cases, as it then is just ones(length (profile),length (profile))
>> Regarding the averaging kernels, they should be converted, even though
>> it means that their peak is at the wrong height. The reason for this
>> comes from the definition of the averaging kernel(see attached file).
>> This means that the averaging kernels for retrieving the relative change
>> from xa and the absolute vmr ARE different. If you try and run the
>> inversion with the same settings converted into vmr(can be a bit tricky
>> depending on your inversion settings) you will see that the averaging
>> kernels will look like the converted ones.
>>
>>
> In my case, it is a retrieval of tropospheric water vapour (nonlinear
> with Marquartd-Levenberg iteration). Due to the large tropospheric H2O
> gradient an absolute ('vmr') retrieval doesn't make sense. Earlier
> tests showed tremendous oscillations with negative xret values.
>> Ill also fix the documentation.
>>
>> Regards
>>
>> Ole Martin
>>
>>
>>
>>
>> On 22/06/11 14:10, Rene Bleisch wrote:
>>
>>> Hi Patrick, I'm a bit confused with the error characterisations when
>>> comparing QPack1 to Qpack2. For the unit='vmr' case, all is clear and
>>> consistent. The use of unit= 'logrel' in Qpack2 resp.
>>> "Q.CLS_SPECIES_POS_ON = 1" in Qpack1 (not x is retrieved but
>>> log(x/xa)) as in my retrieval case, leads to inconsistencies in error
>>> calculation between Qpack1 and Qpack2 and in QPack1 itself.
>>>
>>> Error calculation: Qp1: S_obs = (unitfac*unitfac') .* (Dy * Se *
>>> Dy'); %unitfac: in my case the a-priori-profile, for the 'vmr'
>>> case a vector of ones A = A - eye(nx,nx); S_smo = A * Sx * A';
>>>
>>> Qp2 : So = G * Se * G'; AI = A - eye(size(A,1)); Ss = AI * Sx * AI';
>>>
>>> => eo = sqrt(diag(S_obs)) resp. sqrt(diag(So)) and es =
>>> sqrt(diag(S_smo)) resp. sqrt(diag(Ss)) => es (Qp1)~ es (Qp2) but
>>> eo(Qp1)<<eo(Qp2)
>>>
>>> Up to now, I assumed eo and es being relative to x for both
>>> versions.
>>>
>>> The difference of the observation error obviously comes from the
>>> application of unitfac in Qpack1.
>>>
>>> In the QPack2 doc it is suggested to convert the L2 data of Qpack2
>>> from logrel to vmr with qp2_rel2vmr* (this includes errors and AVK),
>>> thus the converted errors are also in absolute values. Surprisingly
>>> the converted observation error is similar to the one of Qpack1. Does
>>> this mean, that the observation error of Qpack1 in reality is given
>>> in absolute values??. This would be inconsistent as at least es
>>> (Qpack1) seems to be relative.
>>>
>>> Further I'm not sure if it makes sense to also convert the averaging
>>> kernel vom logrel to vmr, as in my case the converted AVK is
>>> completely useless for me. E.g. the maxima are in the stratosphere
>>> (whereas the unconverted AVK is similar to the AVK from Qpack1 with
>>> maxima in the troposphere). Thus I tend to convert only x and xa by
>>> an own function.
>>>
>>> Regards René
>>>
>>>
>>> * in the doc, sect. 6.4.3 a function called "qp2_rel2logrel" is
>>> mentioned, but I think it should be "qp2_rel2vmr"
>>>
>>>
>> _______________________________________________
>> qpack mailing list
>> [email protected]
>> https://www.sat.ltu.se/mailman/listinfo/qpack
>>
>>
>
_______________________________________________
qpack mailing list
[email protected]
https://www.sat.ltu.se/mailman/listinfo/qpack
