Hi Rene,
the RT schemes in ARTS 1 and 2 are not identical, so some differences are
expected. 1 K seems a bit on the large side, but .2 K can easily be due to this.
Basically, the two programs should converge if ppath_lmax and the corresponding
ARTS1 variable l_step are small enough. (And, especially for ARTS1, p_grid also
has to be fine enough.) Some of the differences have to do with how the
atmosphere and the absorption are assumed to behave between the grid points, so
it is to some extent a matter of definition.
If you set both p_grid step and the integration step variables to 100 m, both
versions should give very similar results. The new version should achieve the
same accuracy with somewhat coarser p_grid than the old version, because
absorption is interpolated in a smarter way.
/Stefan
On Jun 20, 2011, at 18:15 , Rene Bleisch wrote:
> Hi Stefan and others,
> in the meantime I could locate the major source of the difference between the
> forward models:
> I forgot to include the O2, N2 and CO2 absorption part in Qpack2/Arts2.
>
> I then made a series of tests with different setups:
> - backend/sensor part and "other tags" (=O2, N2, CO2) disabled
> - backend/sensor enabled
> - "other tags" enabled
> - all enabled
>
> The used H2O a-priori profiles are calculated from a monthly climatology from
> radiosoundings combined with actual surface data from our meteo station, as I
> use it for my retrievals. The O2, N2 and CO2 a-prioris are also climatologies
> but kept constant. The forward model calculations were performed for H2O data
> from Mai to mid-June in a 2hour-resolution (~550 different cases).
>
> "dfy.eps" and "rfy.eps" show timeseries of the absolute resp. relative
> differences between QPack1/Arts1 and QPack2/Arts2 Forward Model at line
> center (22.23 GHz). "fy.eps" shows timeseries of the absolute values, the
> color code is the same as for dfy.eps and rfy.eps, circles show QPack1/Arts1,
> lines Qpack2/Arts2.
>
> In summary, the results are quite satisfactory, but still a small difference
> of 0.2 to 1 K (or 1-2%) remains, nearly independent of whether the backend or
> "other tags" are enabled.
>
> I will continue testing the Forward model, and currently I'm performing a set
> of retrievals to see the influence of the changes on the forward model.
>
> Regards
> René
>
>
> PS
> Here the main setup of my forward models/retrievals (if not written
> otherwise, the setup is identical in both versions):
> - frequency range: 22.235 GHz +/- 1GHz
> - Lines: from HITRAN (Arts1: fmin=0, fmax=10^18)
> - Lineshape: Lorenz (quadratic, cutoff=-1)
> - H2O-model: H2O-PWR98
> - Sensor: Altitude 905m, zenith angle: 30°
> in Qpack/Arts1, groundSet{z = 905, e = 0}, z_plat { value = 905};
> za_pencil=30
> in Qpack/Arts2, sensor_pos= 6378905m (r_geoid is added to z_platform by
> default in Qpack2), z_surface=905m; sensor_los=30
>
> - Vertical grid setup:
> - ppath_lmax=500 (corresponding to Q.STEPLENGTH_RTE = 500 in QPack1, resp
> l_step=500 in Arts1)
> - H2O a-priori: snd climatology+surface value from meteostation, vertical
> grid resolution ~1km;
> - pTz: ECMWF+surface value, vertical grid resolution: ECMWF-grid (increasing
> from ~200m at 1km to 500 m at the tropopause); identical in Qpack1 and 2
> - p-grid (retrieval grid): vertical resolution ~1km;
>
> Notice: in Qpack1/Arts1, the interpolation of the pTz and vmr grids to the
> final grid seems to be done in Arts1 (all vmr grid-files contain also their
> corresponding p-coordinates), whereas Qpack2 already performs the
> interpolations and the xmls for Arts2 need to contain the data on a unique
> vertical grid. (here all a-priori vmr-profiles are merged to a tensor in one
> xml.file, without the corresponding vertical coordinate).
> Could this difference in interpolation lead to a difference in forward model
> output?
>
> On 20.06.2011 09:26, Stefan Buehler wrote:
>> Hallo René,
>>
>> Things to look at, perhaps:
>>
>> - Are the absorption settings really the same (same H2O continuum, etc.)?
>> - What is the vertical grid spacing of your atmoshere? If this is relatively
>> coarse, it may be a good idea to set: "NumericSet( ppath_lmax, 250 )" in the
>> controlfile. (The default value for this in general.arts is 1000, which is a
>> bit large.)
>>
>> /Stefan
>>
>> On Jun 16, 2011, at 14:21 , Rene Bleisch wrote:
>>
>>
>>> Hi Patrick,
>>> - Sensor/backend: removing the sensor/backend part lead to no
>>> improvements, the differences are still the same
>>> - Forward model: For the same example a-priori vmr, Arts1 delivers a
>>> spectrum with 43.1 K at the center frequency of 22.235 GHz, Arts2 a
>>> spectrum with only 39.7 K (Rayleigh-Jeans BT) resp. 40.2 K (Planck BT)
>>> at 22.235 GHz using the settings from the retrievals, the deviation
>>> slightly increases with frequency. Thus choosing Planck or RJ matters,
>>> but the difference is small (only 0.5 K in the example).
>>>
>>> Hence the problem obviously seems to be in the Forward modelling and not
>>> in the retrieval itself. I will now carefully go through the entire
>>> forward model setup for both versions (which should be the same).
>>>
>>> Regards,
>>> René
>>>
>>>
>>> PS: During the tests with no sensor/backend part, I discovered that
>>> Qpack2 ends with an error, if y is chosen in L2_EXTRA and the
>>> sensor/backend are disabled.
>>> Qpack2 then crashes because qp2_l2 takes L2.f from Q.SENSOR_RESPONSE_F
>>> (line 137). But as the backend is disabled, neither this variable
>>> (containing the name of the xml-file with the sensor-response frequency
>>> grid) nor the xml-file itself are created during the processing.
>>>
>>>
>>>
>>> On 15.06.2011 14:47, Patrick Eriksson wrote:
>>>
>>>> Hi René,
>>>>
>>>> My answer is in line with the one of Stefan. The first step is to
>>>> check if you get the same spectrum from the two forward models, for
>>>> the same input. That is, no inversions involved. First test without
>>>> sensor. And if OK, include also the sensor.
>>>>
>>>> Looking a bit on the retrieval part. The logrel unit is the most
>>>> tricky one. If the tests above are all OK, please compare weighting
>>>> functions for rel/frac.
>>>>
>>>> Just ask if anything is unclear. I want of course to know if there is
>>>> a bug soemwhere. That can happen even in ARTS/Qpack ;-)
>>>>
>>>> Bye,
>>>>
>>>> Patrick
>>>>
>>>> On 06/15/2011 12:47 PM, Rene Bleisch wrote:
>>>>
>>>>> Hi all,
>>>>> I use Qpack to retrieve tropospheric water vapour profiles from spectra
>>>>> of our 22GHz radiometer MIAWARA. The setup is like this:
>>>>> - nonlinear Marquardt-Levenberg
>>>>> - polyfit (1st grade, coefficients are part of the state vector and are
>>>>> retrieved)
>>>>>
>>>>> Till recently, I used the old Qpack1 and it worked well. Some months ago
>>>>> I started trying to setup the same retrieval with QPack2. As it didn'
>>>>> work well and I had a lack of time, I gave it then up. Now I retried it
>>>>> and it works quite well with QPack2 after setting the retrieval unit to
>>>>> logrel (implicitly the Qpack1-retrieval was set to logrel, what I only
>>>>> discovered thanks to Patriks suggestions).
>>>>>
>>>>> Still the results with QPack2 differ from the results with QPack1, as
>>>>> the vmr is generally up to 20% too low in upper troposphere and 10-20%
>>>>> too high in lower troposphere. More detailed analyses revealed that
>>>>> there is a difference between the weighting functions in Qpack1 and
>>>>> Qpack2 (even in the first iteration step), the tropospherical maxima of
>>>>> the weighting functions in Qpack2 are generally up to 10% lower than in
>>>>> Qpack1.
>>>>>
>>>>> Does anyone have an idea where this difference could come from?
>>>>> (spectroscopy and pTz setup are identical)
>>>>>
>>>>> Maybe it has to do something with the sensor/backend-part, which should
>>>>> in principle be the same for both. In Qpack1 the H-matrix (y=H*F(x,b))
>>>>> summarizes the entire sensor/backend stuff. I wanted to compare H with
>>>>> its equivalent in QPack2, but I could not find it. Does there exist a
>>>>> similar H-matrix in Arts2/QPack2?
>>>>>
>>>>> Regards
>>>>> René
>>>>>
>>>>>
>>>>>
>>>>
>>> --
>>> René Bleisch
>>> Institute of Applied Physics
>>> University of Bern
>>> Sidlerstr.5
>>> 3012 Bern
>>> Switzerland
>>>
>>> Phone: +41 31 631 89 59
>>> Mail: [email protected]
>>>
>>>
>>> _______________________________________________
>>> qpack mailing list
>>> [email protected]
>>> https://www.sat.ltu.se/mailman/listinfo/qpack
>>>
>>
>>
>
> --
> René Bleisch
> Institute of Applied Physics
> University of Bern
> Sidlerstr.5
> 3012 Bern
> Switzerland
>
> Phone: +41 31 631 89 59
> Mail: [email protected]
>
>
> <dfy.eps><fy.eps><rfy.eps>
_______________________________________________
qpack mailing list
[email protected]
https://www.sat.ltu.se/mailman/listinfo/qpack
