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
[email protected]
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
_______________________________________________
arts_dev.mi mailing list
[email protected]
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
