Hi Karina, Hi Patrick,

is there a reason this discussion is not going via the arts users
mailinglist? I redirect it there now - other people might have helpful
input as well as other people might have/had/ run into similar issues and
benefit from the discussion.
Then, there seems to have been some amount of personal communication
between you two, so I might have missunderstood some things...

I agree with Patrick, at first try out scat_dataCheck with
This should identify all the clearly invalid scat_data. invalid are: NaN
anywhere in K, Z, a and negatives in K11, Z11, a1 (the other Stokes
elements are ok to be negative).

You can (and should in a first try) send the scat_data_raw (your original,
non-f_grid interpolated scattering data) through it.
If that brings up anything, something in your raw data is wrong. In this
case you need to check the source of your scattering data. Might be that
your TMatrix or DDA code provides that, or that your to-arts-xml-format
wrapper is doing something wrong. (there is of course the slight
possibility that something in the ARTS code is buggy - we haven't used
oriented particles very much, ie some of the related code is not tested
intensely and some bugs might have slipped through. I hope, though, that
not at this simple check level...)

When scat_data_raw passes the 'sane' test, try with scat_data. If this
passes, then we should be fairly safe against invalid data (I am not sure,
whether we allow the user to choose the interpolation order anywhere for
the scat_data. higher order polynomials might lead to re-introduction of
negative values... Did you ever change any interp_order settings in
connection with scat_data, Karina?)

Regarding the scattering matrix normalization. This is important to ensure
energy conservation (importance depends on scattering solver used - RT4 is
quite sensitive, while Disort is not at all).
The error message you showed, Karina, suggests quite big deviations from
the expected normalization. It simply means that the scattering cross
section calculated from the integral of Z11 is almost double as high as the
scattering cross section derived from the difference of K11 and a1 (the
extinction and absorption cross sections, respectively).

This might be due to a too coarse angular grid of the scat_data (ARTS so
far uses trapezoidal integration in angle space. with scattering function
being rather not linear, accurate trapezoidal integration requires fairly
fine data grids - some of us working on a better solution, particularly for
oriented particles. but it's not ready yet.). if this is the cause of the
problem, the issue should get more serious with particles getting larger.
Can you observe such a pattern - do small particles pass through, and
larger fail? if so, could you afford to increase the number of zenith and
azimuth angles that your data is reported on?

Another reason might be that the check is actually buggy (as said above,
it's not intensely tested). If all the above reasons have been excluded, I
might need to have a closer look to the ARTS code and your data.

A workaround for the normalization issue is to run scat_data_checkedCalc
with check_level='sane' (that's triggering scat_data_checkedCalc's internal
call to scat_dataCheck to run with check_type='sane', ie skipping the
scattering matrix normalization test). Alternatively, you could set
sca_mat_threshold to (a value close to) 1.
However, you need to be VERY EXTREMELY ABSOLUTELY careful with this and
critically evaluate the RT results. These workarounds will make your case
compute, but with no guarantee whatsoever that the results are still
anywhere near correct.

Last but not least:
> I was wondering if it is possible for ARTS to do the
> absorption vector calculation, or if this must be included as input?

you can. there is a TMatrix interface (scat_data_singleTmatrix). I'm not
sure though, what its maintenance state is (we found that the 3rd party
TMatrix code behind gets unstable for the aspect ratios we were interested
in, hence we moved on to using DDA. externally, then using the data as
input in ARTS).

Btw, is there a reason why you are particularly interested in the
absorption vector? Do you need scattering calculations at all, or would you
do with neglecting the scattering of the particles and only consider their
absorption and emission?

Best wishes,

On Mon, Apr 8, 2019 at 1:40 PM Patrick Eriksson <
patrick.eriks...@chalmers.se> wrote:

> Hi Karina,
> A quick but brief answer. I am very busy this week.
> If you have large negative absorption vector values, something is wrong.
> But I assume that the problems is mainly related to that the
> representation of the scattering data is a bit coarse in ARTS.
> I attach the description of scat_dataCheck. Try to set "check_type" to
> "sane" and see if your data get through. And if then the results look OK.
> Jana: Do you have time to elaborate? Karina works with oriented particles.
> Bye,
> Patrick
> virga|~: arts -d scat_dataCheck
> *-------------------------------------------------------------------*
> Workspace method = scat_dataCheck
> ---------------------------------------------------------------------
> Furthermore, by default it is checked that *scat_data* does not
> contain any invalid values and that the scattering matrix is
> properly normalized. Proper normalization is defined by the maximum
> allowed albedo deviation *sca_mat_threshold* (for details see
> *scat_dataCheck*).
> Method for checking the validity and consistency of the single
> scattering properties in *scat_data*.
> This function checks that *scat_data* does not contain any NaN and
> that the 'scalar' properties K11, Z11, and a1 are non-negative.
> When *check_type* is 'all', this function checks that the solid
> sphere integrated scattering matrix (int_Z11), which is supposed to
> be normalized to the scattering cross section, is sufficiently
> consistent with the scattering cross section (C_sca) derived from
> the difference of extinction (K11) and absorption (a1):
> int_z11 ~ C_sca = K11-a1.
> The check is skipped if *check_type* is 'sane'.
> Sufficient consistency is defined by the maximum allowed deviation
> in single scattering albedo, *sca_mat_threshold*, testing for
>    ( <int_Z11>/<C_sca>-1. ) * ( <C_sca>/<K11> ) <= sca_mat_threshold.
> Synopsis:
> scat_dataCheck( scat_data, check_type,
>                  sca_mat_threshold )
> Authors: Claudia Emde, Jana Mendrok
> Variables:
> IN    scat_data (ArrayOfArrayOfSingleScatteringData):
>        Array of single scattering data.
> GIN   check_type (String, Default: "all"):
>        The level of checks to apply on scat_data (see above).
> GIN   sca_mat_threshold (Numeric, Default: 5e-2):
>        Threshold for allowed albedo deviation (see above).
> *-------------------------------------------------------------------*
> On 2019-04-08 13:47, Karina McCusker wrote:
> > Hi Patrick,
> >
> > Hope you are keeping well!
> >
> >
> > I have been concentrating on other topics of my PhD but am now back to
> > looking at ARTS. You may remember that I wanted to input my own
> > scattering calculations. I thought I had implemented them correctly
> > after testing with the spheroidal case. However, for a large number of
> > the particles I’m now using, I am running into one of 2 problems -
> > either the absorption vector is negative, or it is not negative but when
> > I try to run ARTS I get an error along the lines of:
> >
> > Run-time error in controlfile: cfile_passive.arts
> >
> > Run-time error in method: scat_data_checkedCalc
> >
> > Deviations in scat_data too large:
> >
> > scat dev [%] 94.3242 at nominal (actual) albedo of 0.127368 (0.247507).
> >
> > Check entry for scattering element 0 of scattering species 0 at 0.
> > frequency, 0. temperature, and 0. incident polar angle!
> >
> > Therefore, I believe I am not calculating the absorption vector
> > correctly. I was wondering if it is possible for ARTS to do the
> > absorption vector calculation, or if this must be included as input?
> >
> > Many thanks for your help,
> >
> > Karina
> >
> >
> > ----------------------------------------------------------------
> >
> > Karina McCusker
> >
> > -PhD Student
> >
> > /Fast, approximate methods for electromagnetic wave scattering by
> > complex ice crystals and snowflakes./
> >
> > /
> > /
> >
> > Room 505, Philip Lyle Building
> >
> > Department of Meteorology
> >
> > University of Reading
> >
> > ----------------------------------------------------------------
> >

Jana Mendrok, Ph.D. (Geoscience)

Email: jana.mend...@gmail.com
Phone : +46 (0)708 860 729
arts_users.mi mailing list

Reply via email to