Hi Patrick, This would only apply to the output of propmat_clearsky and not to the transmission matrix. The matrix exponent is not symmetric anymore. So at that point it is easier to store the actual matrix. The matrix exponent itself can be handled for some distance in an internal function of PropagationMatrix, so we can skip the copying we are doing at present to apply the "negative distance" multiplication. I'll make an analytical solution to the matrix inverse as well, since this is also quite easy with sympy. The same with the matrix-vector multiplication and whatever else we use on the current propmat_clearsky. In fact, if it helps I can make the inverse multiplication, which is what we are actually after, so we do not have to generate more temporary variables than necessary. Is there anything else we are actually doing with the propagation matrix? Other than 1/K * S' and exp(-K r) that is?
I agree that the added complexity of splitting this into cases of Zeeman and Faraday might be too much. The advantage is that we can then output their absorption as pure functions of temperature, pressure, and magnetic field strength. Thus, for every frequency, if we set up an interpolation over T, P and |H| we can compute the polarized absorption from the interpolated value. The orientation of the polarization is just two angles per level and these are very easy to compute from the magnetic field and the satellite field of view. It is perhaps easier for now to do as you suggest and keep all the 7 variables around whenever stokes_dim==4. I will make the intermediary step of having the simplified Zeeman calculations clear if anyone is interested in creating a lookup-table adaptation for in the future. //Richard 2017-06-23 19:15 GMT+09:00 Patrick Eriksson <[email protected]>: > 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
