Hi Patrick,

I agree with your proposed changes.

/Stefan

> On 09 Nov 2016, at 20:40, Patrick Eriksson <patrick.eriks...@chalmers.se> 
> wrote:
> 
> Hi all,
> 
> We (Jana and Patrick) have discovered several issues the last weeks 
> around the SingleScattering data format.
> 
> 1. Definition of direction
> -
> A direction can be specified by how the photons move, or in what
> direction you observe to detect the photons. The radiative transfer
> functions in ARTS use the later definition, and call this a
> line-of-sight (LOS). We have not found a clear statement if the
> scattering data format assumes photon directions or LOS. In fact,
> different assumptions have been made in DOIT and MC. In MC, LOS values
> are mirrored before extracting scattering properties, while this is not
> done in DOIT.
> Our discussion of scattering data follows Mishchenko et al (2002) and we
> should stick to it. With this interpretation, presently MC is doing the
> right thing. As far as we understand, the issue has no influence on DOIT
> for random orientation. For horizontally aligned particles, all is OK
> for stokes_dim 1 and 2 (due to reciprocity), but there are issues
> for higher stokes_dims (namely sign errors in the lower left and upper right 
> matrix blocks).
> 
> 
> 2. Azimuth angle
> -
> In ARTS' definition of LOS the azimuth angle is counted clockwise, while
> for scattering data the azimuth angle goes in the opposite direction
> (Fig 6.1 in ATD, and is consistency with Mishchenko et al (2002)). This
> is not considered by either MC and DOIT, and should give a sign error
> for stokes_dim 3 and 4.
> 
> 
> 3. Format for "horizontally aligned"
> -
> We have now realized that this format is not as general as we (at least
> JM+PE) thought. It does not treat all horizontally aligned or azimuthally 
> randomly oriented particles. The (orientation averaged) particles must 
> also be symmetric around the horizontal plane. Such a symmetry will 
> rather be the exception when working with arbitrarily shaped particles 
> (and using DDA) and also, e.g., excludes realistically shaped rain drops. 
> We could introduce a new format for this, but that would make code and 
> documentation even more complicated.
> Expressed simply and discussing the phase matrix, we currently store the 
> left part of the matrix holding data for incident and scattered zenith angles 
> (in table cols and rows, respectively).  By making use of the reciprocity 
> theorem, 
> we could get away by storing just the upper triangle, i.e. with the same 
> amount 
> of data as now. But that would make the internal storage more complicated and 
> require more heavy calculations to extract the data (not just sign changes 
> are 
> needed, a transformation matrix, though simple, must be applied). So we just 
> simply suggest that we store the complete phase matrix. That is, the incoming 
> zenith directions will be [0,180] and not just [0,90] as now. And to keep 
> things as
> simple as possible we suggest to do the same for abs_vec and ext_mat.
> We don't need to change the fields in the data format, but this should still 
> be a 
> new version of the format. And when we are introducing a new format we would
> also like to rename the "ptypes" as well, as "horizontally_aligned" is not a 
> good 
> name when we start to work with tilted particles. We suggest the names
>   totally_random
>   azimuthally_random
> 
> (We are not 100% sure about some of the theoretical details, but the
> three main remarks should still be valid.)
> 
> Any comments or opinion?
> 
> We (mainly Jana) plan to start attacking these things relative soon. If
> anybody wants to help out in the revision, please let us know.
> 
> Bye,
> 
> Patrick and Jana
> _______________________________________________
> 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

Reply via email to