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
