Hi Stefan,
In general I agree to not put all checks in the same function. But this
is not a clear cut case. The size of scat_data shall be consistent with
pnd_field, that in its turn should be consistent with cloudbox_limits.
So no clear place where to separate scat_data and other cloudbox checks.
In fact cloudbox_checkCalc already contains some checks of scat_data.
Which makes sense for me. scat_data, pnd_field and cloudbox_limits are
the main "cloudbox variables".
Another reason that if we introduce scat_data_check, we must add it to a
number of ARTS WSMs. And modify many many cfiles. Just personally
probably need modify about 50 scripts if scata_dataCheck becomes mandatory.
Bye,
Patrick
On 2016-08-26 13:38, Stefan Buehler wrote:
Hi all,
I agree with Patrick that a mandatory check method is the best
solution. :-)
But modernising scat_dataCheck and making it mandatory (via a
_checked flag) seems cleaner to me than including it in the cloudbox
check. Better not to entangle issues that can be regarded separately.
These check functions seem to have evolved as a general strategy, I
think they are quite intuitive and user friendly. More so if their
scope is limited and clear, less if there is a single huge check
function that does all kinds of things.
All the best,
Stefan
P.s.: Jana, I think this is really great work, and very timely.
Oliver and I spent some time yesterday looking at your test case and
debugging the scat data merging method. So, the comparison of the
different solvers has already been fruitful to squash bugs.
On 26 Aug 2016, at 08:59, Patrick Eriksson
<[email protected]> wrote:
Hi Jana,
I did not have scat_dataCheck active in my memory. I think this is
a lesson that non-mandatory stuff will be forgotten. To avoid nasty
errors and incorrect results, we should make most basic checks
mandatory.
My suggestion is then to extend cloudbox_checkedCalc. My view on
cloudbox_checkedCalc is that the tests we discuss are in fact
inside the scope of the WSM. So just strange that they are not
already there!
(If some tests turn out to be computationally demanding, then I
prefer to have option flags of type "I know what I am doing", to
deactive the checks.)
Regarding normalisation, how big difference is there between
quadrature rules? 1%, 10% or 100%? Seems reasonable to at least
check that normalisation is OK inside a factor of 2. (With an
option to deactive this, if you use a solver anyhow checking
this.)
Bye,
Patrick
On 2016-08-25 20:10, Jana Mendrok wrote:
Hi,
i'm currently implementing an interface to the RT4 solver and am
testing it. that was at least the original plan. partly it
however turns out to be more of "fall into the traps" and
"stumble upon issues" with other the solver (which i intended to
use as reference)...
current issue i stumbled upon is that there seems to be no
(sufficiently) rigid test on validity (or at least
eligibility/adequacy/proper qualification) of the scattering
data (scat_data).
i've created my scat_data from ARTS' TMatrix interface. Happened
that one of the particles was too challenging for TMatrix and
produced a couple of NaN and also negative extinction and
absorption coefficients (K11 and alpha1). while NAN could be
avoided (equ. to a TMatrix fail), it's hardly possible for the
negatives (they are "regular" TMatrix output.
ARTS scatt solvers reacted very different on the presence of
these invalid data: - RT4 gave a runtime error due to scatt
matrix normalization being too far off (guess, Disort would do
the same. wasn't tested here as I used oriented particles, which
aren't handled by Disort). - DOIT ran through providing results
that looked not immediately suspicious :-O - MC ran into an
assertion within an interpolation.
that's quite unsatisfactory, i think, and should be handled in
some consistent manner, i think. question is how. some ideas
below. do you have some further ideas or suggestions or
comments?
appreciate any input. wishes, Jana
my thoughts/ideas:
- leave it to each solver to check for that (but then we need to
go over them to do that)?
- make an additional check method and another check variable for
the scat_data? there is already a scat_dataCheck WSM. which is
rarely used. it e.g. checks that scat_data cover the required
frequencies, but also the scatt matrix normalization, the latter
only available for random orientation, though. in my experience
it hasn't been too helpful (data coming from atmlab Mie interface
- as well as from ARTS' Tmatrix interface as i learned these days
- frequently don't pass the normalisation check. which is beside
others due to the type of quadrature used. according to my
experience, such norm issues are better handled by each solver
separately), and since it's not mandatory, i avoid it. but it
would be an option to modify this (make the norm check optional,
instead check for nan and negative values) and make it mandatory
(through a checked flag).
- an issue is, of course, that one does not really want to check
data, that is frequently used, each time again (e.g. the
arts-xml-data contents, data from the future ice/snow SSP
database we are creating...) for those invalid entries. so maybe
giving the data structure itself a flag and providing a WSM that
does that checking and resets the flag? the above checked method
could e.g. look for this flag and apply the whole check suite
only on so far unchecked data.
--
=====================================================================
Jana Mendrok, Ph.D. (Project Assistent)
Chalmers University of Technology Earth and Space Sciences SE-412
96 Gothenburg, Sweden
Phone : +46 (0)31 772 1883
=====================================================================
_______________________________________________
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
_______________________________________________ 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
