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 <mailto: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
