Re: [arts-dev] RT4 and auto-increasing number of streams - a cautionary note

[Jana Mendrok]

Hi,

Victoria, Patrick, great that you were aware of that! cause, last time i
talked with someone (manfred, maybe?), I myself was not aware of it
anymore. realising that is why I sent this note in the beginning...

regarding Patrick's question - at least the intensity component is getting
smoother with more scattering, i.e. the interpolation does not get more
serious with stronger scattering (i don't have a good feeling for higher
stokes components. there it might depend, e.g. on the surface properties.).

My main concern comes from the interplay of RT4 with ARTS: Using the
auto-increase-streams feature, first the radiation field is calculated with
high(er) angular resolution (as high as the phase-function norm
reproduction (aka energy conservation) requires), then this
high-angular-resolution-field is interpolated onto the low-resolution
original angular grid in the RT4 interface and last, in
(i)yCalc/iyEmissionStandard, the radiation value at a given angle is
extracted by interpolation.

It's this 2-step interpolation with the first one degrading resolution that
worries me (it feels safer to have only one interpolation step. or,
alternatively, to at least go from low to high resolution in the first
step, not the other way round. either requires some additional internal
logistics, though - which is why it hasn't been done like that yet.)

Moreover, the iyEmissionStandard interpolation is hardcoded to a linear
interpolation (in angle space) so far - which should maybe be replaced in
any way, since this is particularly bad; both higher order polynomials and
interpolation in cos(angle) space seem (!) to give better results.
Interpolation in the RT4 interface can be controlled by the user, selecting
the interpolation order and the interpolation space (angle or cos(angle));
the default so far, though, is also linear in angle space (for consistency
with iyEmissionStandard and because it's not very clear, which setup is
best. or consistently good. would need a bit more testing... if anyone has
time...).

Victoria, I get back to you separately regarding your specific questions.

best wishes,
Jana


On Wed, Jan 24, 2018 at 8:00 PM, Victoria Sol Galligani <
victoriasgallig...@gmail.com> wrote:

> Hello everyone! Hi Jana!
>
> I was aware of what you are saying about the number of streams. However
>  in the context of the ARTS scattering methods + RTTOV-scatt
> inter-comparison I am working on, I have been testing the sensitivity of
> the output TBs to the number of streams chosen. In this regard, I think it
> would be interesting to run RT4 even if the interpolation induces large
> errors and the scattering matrix is not resolved well. If I run RT4 without
> this warning (actually error because arts doesn't run with its current
> checks) I could easily answer your answer Patrick (if the angle
> interpolation error increases with strong scattering), because I'm running
> with different profiles, some with much more scattering than others. At the
> moment its clear to me that more streams are needed for more scattering
> cases, so I guess that already answers your question Patrick ...
>
> Do you have any advice regarding turning this warning/error off on my arts
> distribution?
>
> Looking forward to sharing my preliminary results on this subject,
> Hugs,
>
> Victoria
>
>
> On Mon, Jan 22, 2018 at 4:56 PM, Patrick Eriksson <
> patrick.eriks...@chalmers.se> wrote:
>
>> Hi Jana,
>>
>> I was aware of that the auto-increase does not change the number of
>> output angles, but still thanks for the warning.
>>
>> That is, for me it was understood that you should check that the start
>> number of streams is high enough, to make sure that angle interpolation
>> does not induce too large errors. But not clear to me is if the angle
>> interpolation error increases with strong scattering. This is something
>> that I have never tested.
>>
>> Your comments seem to indicate that it is the case (i.e. increasing
>> errors), but has you tested it? Without that it is a bit hard to decide
>> what to do.
>>
>> Anyhow, my recommendation is that you focus on general cleaning and
>> documentation. Leave any possible extension of RT4 on this point to us
>> others, if we find it necessary.
>>
>> Bye,
>>
>> Patrick
>>
>>
>>
>>
>>
>> On 2018-01-22 17:46, Jana Mendrok wrote:
>>
>>> Hi,
>>>
>>> With some of you we have discussed (even suggested) the use of the
>>> auto-increase number of streams feature of the RT4 interface.
>>> The background to this feature is that RT4 needs the scattering matrix
>>> to be properly resolved in order to conserve the scattered energy
>>> satisfactorily. Using the feature, the number of streams is internally(!)
>>> increased until the scattering matrix resolution is deemed sufficient.
>>>
>>> The crucial issue, i just got reminded of when i went through the code,
>>> is that this increase is only done internally. the output will remain on
>>> the original number of streams set!
>>>
>>> That means, *one should n

Re: [arts-dev] RT4 and auto-increasing number of streams - a cautionary note

[Patrick Eriksson]

Hi Victoria,

Some comments, just in case ...

My question just referred to if the radiation field gets more flat or 
more varying (as a function of zenith angle) with increased scattering. 
And thus if the issue if angular interpolation gets more serious or not. 
The overall calculation accuracy should just increase with the number of 
streams.


At this moment I leave to Jana to comment on checks and warnings 
associated with the scattering data.


Bye,

Patrick



On 01/24/18 20:00, Victoria Sol Galligani wrote:

Hello everyone! Hi Jana!

I was aware of what you are saying about the number of streams. However 
 in the context of the ARTS scattering methods + RTTOV-scatt 
inter-comparison I am working on, I have been testing the sensitivity of 
the output TBs to the number of streams chosen. In this regard, I think 
it would be interesting to run RT4 even if the interpolation induces 
large errors and the scattering matrix is not resolved well. If I run 
RT4 without this warning (actually error because arts doesn't run with 
its current checks) I could easily answer your answer Patrick (if the 
angle interpolation error increases with strong scattering), because I'm 
running with different profiles, some with much more scattering than 
others. At the moment its clear to me that more streams are needed for 
more scattering cases, so I guess that already answers your question 
Patrick ...


Do you have any advice regarding turning this warning/error off on my 
arts distribution?


Looking forward to sharing my preliminary results on this subject,
Hugs,

Victoria


On Mon, Jan 22, 2018 at 4:56 PM, Patrick Eriksson 
mailto:patrick.eriks...@chalmers.se>> wrote:


Hi Jana,

I was aware of that the auto-increase does not change the number of
output angles, but still thanks for the warning.

That is, for me it was understood that you should check that the
start number of streams is high enough, to make sure that angle
interpolation does not induce too large errors. But not clear to me
is if the angle interpolation error increases with strong
scattering. This is something that I have never tested.

Your comments seem to indicate that it is the case (i.e. increasing
errors), but has you tested it? Without that it is a bit hard to
decide what to do.

Anyhow, my recommendation is that you focus on general cleaning and
documentation. Leave any possible extension of RT4 on this point to
us others, if we find it necessary.

Bye,

Patrick





On 2018-01-22 17:46, Jana Mendrok wrote:

Hi,

With some of you we have discussed (even suggested) the use of
the auto-increase number of streams feature of the RT4 interface.
The background to this feature is that RT4 needs the scattering
matrix to be properly resolved in order to conserve the
scattered energy satisfactorily. Using the feature, the number
of streams is internally(!) increased until the scattering
matrix resolution is deemed sufficient.

The crucial issue, i just got reminded of when i went through
the code, is that this increase is only done internally. the
output will remain on the original number of streams set!

That means, *one should not start with a very low number of
streams* and should not let the system completely self-adapt
(as, strictly speaking, that's not what it is doing - the output
dimensions won't adapt and will always remain the
original/starting number of streams) (i'm going to add that info
to the online doc).

It should be kept in mind, that - unlike Disort - neither RT4
nor ARTS itself have good interpolation options for "off-stream"
angles, i.e. the number of streams RT4 is set up with does not
only determine the RT4 solution accuracy (this is
improved/adapted with the auto-increase feature), but also the
number of output directions (not affected by auto-increase),
hence the accuracy with which the field is known to and further
applied within other WSM of ARTS.

Best wishes,
Jana


Ps.  Something more for developers...

Thinking about that, this seems quite inconvenient. So, the
question what to do about it, how to change that. Two possible
solutions pop into my head:

(1) instead of interpolating the high-stream-solution to the low
number of streams, we could interpolate everything to the
highest number of streams and output the "high-resolution" field.

(2) re-define (doit_)i_field from Tensor7 into a ArrayOfTensor6
with one Tensor6 entry per freq. this would allow to have
different angular dimensions per frequency (we'd need to also
store the angles per each frequency). however, that would affect
the output of other solvers, too, and the way (doit_)i_field is

Re: [arts-dev] RT4 and auto-increasing number of streams - a cautionary note

[Victoria Sol Galligani]

Hello everyone! Hi Jana!

I was aware of what you are saying about the number of streams. However
 in the context of the ARTS scattering methods + RTTOV-scatt
inter-comparison I am working on, I have been testing the sensitivity of
the output TBs to the number of streams chosen. In this regard, I think it
would be interesting to run RT4 even if the interpolation induces large
errors and the scattering matrix is not resolved well. If I run RT4 without
this warning (actually error because arts doesn't run with its current
checks) I could easily answer your answer Patrick (if the angle
interpolation error increases with strong scattering), because I'm running
with different profiles, some with much more scattering than others. At the
moment its clear to me that more streams are needed for more scattering
cases, so I guess that already answers your question Patrick ...

Do you have any advice regarding turning this warning/error off on my arts
distribution?

Looking forward to sharing my preliminary results on this subject,
Hugs,

Victoria


On Mon, Jan 22, 2018 at 4:56 PM, Patrick Eriksson <
patrick.eriks...@chalmers.se> wrote:

> Hi Jana,
>
> I was aware of that the auto-increase does not change the number of output
> angles, but still thanks for the warning.
>
> That is, for me it was understood that you should check that the start
> number of streams is high enough, to make sure that angle interpolation
> does not induce too large errors. But not clear to me is if the angle
> interpolation error increases with strong scattering. This is something
> that I have never tested.
>
> Your comments seem to indicate that it is the case (i.e. increasing
> errors), but has you tested it? Without that it is a bit hard to decide
> what to do.
>
> Anyhow, my recommendation is that you focus on general cleaning and
> documentation. Leave any possible extension of RT4 on this point to us
> others, if we find it necessary.
>
> Bye,
>
> Patrick
>
>
>
>
>
> On 2018-01-22 17:46, Jana Mendrok wrote:
>
>> Hi,
>>
>> With some of you we have discussed (even suggested) the use of the
>> auto-increase number of streams feature of the RT4 interface.
>> The background to this feature is that RT4 needs the scattering matrix to
>> be properly resolved in order to conserve the scattered energy
>> satisfactorily. Using the feature, the number of streams is internally(!)
>> increased until the scattering matrix resolution is deemed sufficient.
>>
>> The crucial issue, i just got reminded of when i went through the code,
>> is that this increase is only done internally. the output will remain on
>> the original number of streams set!
>>
>> That means, *one should not start with a very low number of streams* and
>> should not let the system completely self-adapt (as, strictly speaking,
>> that's not what it is doing - the output dimensions won't adapt and will
>> always remain the original/starting number of streams) (i'm going to add
>> that info to the online doc).
>>
>> It should be kept in mind, that - unlike Disort - neither RT4 nor ARTS
>> itself have good interpolation options for "off-stream" angles, i.e. the
>> number of streams RT4 is set up with does not only determine the RT4
>> solution accuracy (this is improved/adapted with the auto-increase
>> feature), but also the number of output directions (not affected by
>> auto-increase), hence the accuracy with which the field is known to and
>> further applied within other WSM of ARTS.
>>
>> Best wishes,
>> Jana
>>
>>
>> Ps.  Something more for developers...
>>
>> Thinking about that, this seems quite inconvenient. So, the question what
>> to do about it, how to change that. Two possible solutions pop into my head:
>>
>> (1) instead of interpolating the high-stream-solution to the low number
>> of streams, we could interpolate everything to the highest number of
>> streams and output the "high-resolution" field.
>>
>> (2) re-define (doit_)i_field from Tensor7 into a ArrayOfTensor6 with one
>> Tensor6 entry per freq. this would allow to have different angular
>> dimensions per frequency (we'd need to also store the angles per each
>> frequency). however, that would affect the output of other solvers, too,
>> and the way (doit_)i_field is applied in (i)yCalc.
>>
>> so, option (1) seems less of a hassle.
>>
>> neither option will solve all issues (like, even if the radiation field
>> is quite smooth, linear interpolation from low-resolution fields won't be
>> very good and higher-order interpolation intrinsically requires, well,
>> higher numbers of streams), but at least some (like better conserving the
>> shape of the radiation field, where derived from higher number of streams).
>>
>> any opinions? do you consider this an issue at all, or is a cautionary
>> note in the documentation enough? if an issue, any better ideas on
>> solutions or opinions on "my" two options?
>>
>> and, anyone other than me willing to implement possible changes?
>>
>>
>> --
>> =

Re: [arts-dev] RT4 and auto-increasing number of streams - a cautionary note

[Patrick Eriksson]

Hi Jana,

I was aware of that the auto-increase does not change the number of 
output angles, but still thanks for the warning.


That is, for me it was understood that you should check that the start 
number of streams is high enough, to make sure that angle interpolation 
does not induce too large errors. But not clear to me is if the angle 
interpolation error increases with strong scattering. This is something 
that I have never tested.


Your comments seem to indicate that it is the case (i.e. increasing 
errors), but has you tested it? Without that it is a bit hard to decide 
what to do.


Anyhow, my recommendation is that you focus on general cleaning and 
documentation. Leave any possible extension of RT4 on this point to us 
others, if we find it necessary.


Bye,

Patrick





On 2018-01-22 17:46, Jana Mendrok wrote:

Hi,

With some of you we have discussed (even suggested) the use of the 
auto-increase number of streams feature of the RT4 interface.
The background to this feature is that RT4 needs the scattering matrix 
to be properly resolved in order to conserve the scattered energy 
satisfactorily. Using the feature, the number of streams is 
internally(!) increased until the scattering matrix resolution is deemed 
sufficient.


The crucial issue, i just got reminded of when i went through the code, 
is that this increase is only done internally. the output will remain on 
the original number of streams set!


That means, *one should not start with a very low number of streams* and 
should not let the system completely self-adapt (as, strictly speaking, 
that's not what it is doing - the output dimensions won't adapt and will 
always remain the original/starting number of streams) (i'm going to add 
that info to the online doc).


It should be kept in mind, that - unlike Disort - neither RT4 nor ARTS 
itself have good interpolation options for "off-stream" angles, i.e. the 
number of streams RT4 is set up with does not only determine the RT4 
solution accuracy (this is improved/adapted with the auto-increase 
feature), but also the number of output directions (not affected by 
auto-increase), hence the accuracy with which the field is known to and 
further applied within other WSM of ARTS.


Best wishes,
Jana


Ps.  Something more for developers...

Thinking about that, this seems quite inconvenient. So, the question 
what to do about it, how to change that. Two possible solutions pop into 
my head:


(1) instead of interpolating the high-stream-solution to the low number 
of streams, we could interpolate everything to the highest number of 
streams and output the "high-resolution" field.


(2) re-define (doit_)i_field from Tensor7 into a ArrayOfTensor6 with one 
Tensor6 entry per freq. this would allow to have different angular 
dimensions per frequency (we'd need to also store the angles per each 
frequency). however, that would affect the output of other solvers, too, 
and the way (doit_)i_field is applied in (i)yCalc.


so, option (1) seems less of a hassle.

neither option will solve all issues (like, even if the radiation field 
is quite smooth, linear interpolation from low-resolution fields won't 
be very good and higher-order interpolation intrinsically requires, 
well, higher numbers of streams), but at least some (like better 
conserving the shape of the radiation field, where derived from higher 
number of streams).


any opinions? do you consider this an issue at all, or is a cautionary 
note in the documentation enough? if an issue, any better ideas on 
solutions or opinions on "my" two options?


and, anyone other than me willing to implement possible changes?


--
=
Jana Mendrok, Ph.D.

Email: jana.mend...@gmail.com 
=

___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

[arts-dev] RT4 and auto-increasing number of streams - a cautionary note

[Jana Mendrok]

Hi,

With some of you we have discussed (even suggested) the use of the
auto-increase number of streams feature of the RT4 interface.
The background to this feature is that RT4 needs the scattering matrix to
be properly resolved in order to conserve the scattered energy
satisfactorily. Using the feature, the number of streams is internally(!)
increased until the scattering matrix resolution is deemed sufficient.

The crucial issue, i just got reminded of when i went through the code, is
that this increase is only done internally. the output will remain on the
original number of streams set!

That means, *one should not start with a very low number of streams* and
should not let the system completely self-adapt (as, strictly speaking,
that's not what it is doing - the output dimensions won't adapt and will
always remain the original/starting number of streams) (i'm going to add
that info to the online doc).

It should be kept in mind, that - unlike Disort - neither RT4 nor ARTS
itself have good interpolation options for "off-stream" angles, i.e. the
number of streams RT4 is set up with does not only determine the RT4
solution accuracy (this is improved/adapted with the auto-increase
feature), but also the number of output directions (not affected by
auto-increase), hence the accuracy with which the field is known to and
further applied within other WSM of ARTS.

Best wishes,
Jana


Ps.  Something more for developers...

Thinking about that, this seems quite inconvenient. So, the question what
to do about it, how to change that. Two possible solutions pop into my head:

(1) instead of interpolating the high-stream-solution to the low number of
streams, we could interpolate everything to the highest number of streams
and output the "high-resolution" field.

(2) re-define (doit_)i_field from Tensor7 into a ArrayOfTensor6 with one
Tensor6 entry per freq. this would allow to have different angular
dimensions per frequency (we'd need to also store the angles per each
frequency). however, that would affect the output of other solvers, too,
and the way (doit_)i_field is applied in (i)yCalc.

so, option (1) seems less of a hassle.

neither option will solve all issues (like, even if the radiation field is
quite smooth, linear interpolation from low-resolution fields won't be very
good and higher-order interpolation intrinsically requires, well, higher
numbers of streams), but at least some (like better conserving the shape of
the radiation field, where derived from higher number of streams).

any opinions? do you consider this an issue at all, or is a cautionary note
in the documentation enough? if an issue, any better ideas on solutions or
opinions on "my" two options?

and, anyone other than me willing to implement possible changes?


-- 
=
Jana Mendrok, Ph.D.

Email: jana.mend...@gmail.com
=
___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi