Hi all,
I think averaging over orientations and over sizes both is not possible.
Since we decided to store optical properties for randomly oriented or
horizontally aligned particles and for e.g. gamma size distributions, it
was not possible to use the amplitude matrix.
Indeed we save a lot of memory, when we store optical properties for a
size distribution rather than for individual sizes.
I also might be wrong because it is very long ago, but like Cory I
remember that we discussed about it.
Best regards,
Claudia
On 23/06/17 13:05, Cory Davis wrote:
Actually, it might have been integrating over orientations that was the
problem.
On Fri, 23 Jun 2017, 10:36 pm Cory Davis, <corzneff...@gmail.com
<mailto:corzneff...@gmail.com>> wrote:
Hi there. It was about 13 years ago, so I could have this wrong, but
I think there was a big discussion between Claudia and l and another
(Christian). The result was that you can't use the amplitude matrix
because it is not linearly related to the extinction and phase
matrices and you need to integrate the latter over incidence and
scattering angles. But it's late here and it was a while ago.
Apologies if this was irrelevant! Cory
On Fri, 23 Jun 2017, 10:15 pm Patrick Eriksson,
<patrick.eriks...@chalmers.se <mailto:patrick.eriks...@chalmers.se>>
wrote:
Hi Richard, hi all,
I notice a trend here!
Simon is looking into how we shall treat covariance matrices.
And he is
also considering to introduce a special class, to allow that we
can make
use of the block structure of such matrices, and also to some extent
make use of the symmetry in such matrices.
Yesterday Robin made the remark that we can save space for
scattering
matrices by instead store the amplitude matrix values. The number of
free variables then decreases from 16 to 7. (Robin correct me if
something is wrong) Seems reasonable for the scattering
database. To be
discussed if this also should be used inside ARTS.
Richard, I see your point and I think this is basically a good idea.
As I wrote in some other email, I think A is valid also for
scattering.
Jana and/or Robin, can you comment/confirm?
Some comments:
Richard, for the discussion you should maybe clarify where this
approach
should be applied. You just discuss "propagation matrix". This
variable
has unit 1/m, but your A must have unit [-]. That is, do you want to
apply the scheme both on propagation matrices and extinction
over some
path length? As I see it, if introduced the approach should be
used as
far as possible and this has consequences around ARTS.
However, the idea of including variables to describe Faraday and
Zeeman
seems overly complex. What do you gain be postponing the impact of
Faraday and Zeeman, instead of including the effect from start
and let
the rest of the machinery be blind to if b != 0 is caused by
Zeeman or
scattering?
For me it seems simplest to just apply a vector here, where [a,
b ...w]
have a specific order. In fact, this is exactly what we do in
the format
for storing scattering data. There we just store the independent
values,
and form the vectors and matrices when imported into ARTS. It
would be
very good if the order we use in the scattering data format could be
used also in the propmat class.
Some comments before starting the midsummer celebrations!
Bye,
Patrick
On 2017-06-22 17:05, Richard Larsson wrote:
> Hi all,
>
> I would like to propose switching to an internal
representation of the
> propagation matrix using a specially designed class,
imaginatively named
> "PropagationMatrix". Some background below. Inputs wanted!
>
> With the help of Philippe Baron, I added a new
matrix-exponent function
> that is about 30X faster than the base implementation. This
> implementation only works for the very specific case when
>
> F = exp(A), and A =
>
> a b c d
> b a u v
> c -u a w
> d -v -w a
>
> This seems to be the case for all matrices that we are
concerned about
> in the propagation parts of ARTS, even in the scattering
cases. Is this
> true?
>
> It is the case for clearsky anyways, so this is kinda nice to
have at
> hands. Thanks Philippe!
>
> Got me thinking, though, that we are wasting a lot of memory
and a lot
> of computing time keeping the entire 4X4 propagation-matrix
around when
> all we really need is just the 7 independents a, b, c, d, u,
v, and w.
> I was originally considering proposing an implementation
change in
> propmat_clearsky to rather use Vectors of these parameters to
represent
> the matrix. However, that would be overly simplistic and
might not be
> beneficiary enough to justify the extra work.
>
> Instead, I would like to propose a similar class,
PropagationMatrix,
> that can store the entire propagation matrix in parameterized
form that
> is reduced to the seven variables above by simple mechanisms.
>
> For unpolarized absorption, the parameterization would just
keep a
> Vector of the absorption, i.e. "a" above.
>
> For Faraday, it would also keep a single Vector of the rotation
> strength, but also a Numeric for the angle between the
magnetic field
> and the line-of-sight. These two are enough to generate "u"
above.
>
> For Zeeman, it would keep three Vectors of the strength and
two angles
> for the magnetic field relative to the line-of-sight. These
are enough
> to generate the 7 parameters.
>
> Are there other cases of propagation requiring care that I am
missing or
> do we only have these three? Probably, and I will simply
store these as
> the 7 parameters.
>
> When all is added up to a final product in the end, only then
would the
> full seven Vectors be used (if necessary) before the
transmission matrix
> is computed.
>
> This PropagationMatrix will of course implement a way to know
how to
> multiply itself with ARTS-matrices and Vectors as the current
> Matrix-representation does. Numerical multiplications are
simpler still.
>
> This would require adding the PropagationMatrix to the global
variables
> that can be read and viewed from the controllfile.
Otherwise, we would
> have to use the same memory-layout as before in every instance of
> interacting with other methods...
>
> The major advantage is in the summation phase where each type of
> propagation matrix knows how it should behave. Simple
diagonal matrices
> don't have to sum to other things than the diagonal. Faraday
to "u".
> Zeeman still has to sum to all but now there are 7 variables
rather than
> 16.
>
> A possible follow-up advantage is that it should make
lookup-table
> calculations possible for Zeeman and Faraday by extending the
> interpolation to include the magnetic strength. The angles
between the
> magnetic field and the line-of-sight is easy to compute
on-the-fly and
> would be all you need to compute the full PropagationMatrix
from the
> interpolated one.
>
> I would like some input before I take on this task though.
>
> With hope,
> //Richard
>
>
> _______________________________________________
> arts_dev.mi mailing list
> arts_dev.mi@lists.uni-hamburg.de
<mailto:arts_dev.mi@lists.uni-hamburg.de>
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
>
_______________________________________________
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
<mailto:arts_dev.mi@lists.uni-hamburg.de>
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
_______________________________________________
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.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
