Dear all, I agree with Patrick. So, in the specific issue raised by Jacob, I vote for simply going back to the old behaviour. It is formally correct to get a clear sky result in a calculation without cloud box, so let’s trust the user that he knows what he is doing.
All the best,
Stefan
> On 7. Jun 2017, at 17:21, Patrick Eriksson <patrick.eriks...@chalmers.se>
> wrote:
>
> Hi Jana and Jakob , hi all,
>
> Before commenting on this particular questions, I see a more general
> discussion here. There are many similar issues. Shall we focus on catching
> potential user mistakes/misunderstandings, or be less restrictive to simplify
> batch/operational processing? For example, I discussed with Simon today how
> OEM shall behave when an error occur during the iterations. (And I liked
> Simon's solution, OEM does not throw an error but flags the problem by an
> output argument. We must trust that the user checks that variable.) Hence, it
> would be good to come up with a general strategy. The question is when and
> how to discuss this?
>
> There will be a bit of ARTS planning next week when Simon and I are in
> Hamburg. Don't know if we will get time to discuss also this, but maybe. So
> you others that will not be in Hamburg, if you have any opinion in this
> matter, send an email so we know about it, if we happen to reach this issue.
>
>
> Regarding the present issue I think it should be possible to use the same
> set-up even if the cloudbox happen to end up to of zero size. If there should
> be some kind of "robust flag" or not, can be discussed.
>
> This in line with my general view. We shall not be too restrictive in our
> tests. Real errors SHALL be caught, but as long as things are formally
> correct I think it is best to let things pass. In the end there could be a
> good reason for doing things that way.
>
> Bye,
>
> Patrick
>
>
>
> On 2017-06-07 14:24, Jana Mendrok wrote:
>> Hi Jakob,
>> thanks for your feedback!
>> it was me who did that change. For the reason you also identified - that
>> otherwise it easily goes unnoticed that actually no scattering has been
>> done. This actually happened to me a few times. And considering that when
>> calling the scattering solver, the user intends to actually perform a
>> scattering calculation. I understand your issues, though.
>> Spontaneously, I don't see an option that satisfies both. Below a couple of
>> options I can think of to deal with this issue (in the ps some option that
>> you yourself could apply. without changes on the official code). Would
>> appreciate feedback from other developers (and users), what you prefer, what
>> is considered more important (my issues of course seem more important - to
>> me. very subjective.). Or maybe you have better ideas how to solve that
>> conflict.
>> so, code-wise we could (either):
>> - generally go back to the old behaviour.
>> - stay with the new behaviour.
>> - introduce a ("robust"?) option to allow the user to control the
>> no-cloudbox behaviour.
>> - make cloudboxSetAutomatocally behave differently for clearsky cases
>> (return a minimal cloudbox? and maybe let the user control which behaviour -
>> minimal or no cloudbox - is applied?).
>> wishes,
>> Jana
>> ps. Some options, you yourself have, Jakob:
>> - you can of course locally remove the newly introduced error throwing and
>> go back to the old behaviour in your own ARTS compilation.
>> - with the current version (no-cloudbox throws error) you could make a
>> "cloudy" run (with empty results for the pure clearsky cases) and an
>> explicit clearsky run and postprocess the results to whatever you need.
>> - you could use a manually set cloudbox (that can be better for some study
>> setups anyways. ensures better comparability between different cases as then
>> they equally affected by scattering solver errors (sphericity, vertical
>> resolution, interpolation, etc.))
>> On Wed, Jun 7, 2017 at 1:26 PM, Jakob Sd <jakobdo...@googlemail.com
>> <mailto:jakobdo...@googlemail.com>> wrote:
>> Hi,
>> recently there has been a change in the way DOIT and DISORT handle
>> atmospheres where the cloud box is switched off (cloudbox_on = 0).
>> Before, they just skipped the scattering calculation, threw a
>> warning, and everything was ok, as the clear-sky calculations
>> afterwards took care of it.
>> But now, they throw a runtime error, which means that the
>> calculation is stopped and the results will be empty for that
>> atmosphere. I understand that this runtime error makes sense if
>> someone wants to calculate with scattering but by mistake switches
>> off the cloud box. But if someone has a batch of atmospheres from
>> which some are clear sky atmospheres and uses
>> cloudboxSetAutomatically, this can be quite uncomfortable, because
>> all the clear sky atmospheres that were correctly calculated before,
>> are now empty and the user has to manually select those atmospheres
>> from his batch and calculate them using clear sky ARTS.
>> Greetings from Hamburg,
>> Jakob
>> _______________________________________________
>> arts_dev.mi mailing list
>> arts_dev.mi@lists.uni-hamburg.de
>> <mailto:arts_dev.mi@lists.uni-hamburg.de>
>> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
>> <https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi>
>> --
>> =====================================================================
>> Jana Mendrok, Ph.D. (Researcher)
>> Chalmers University of Technology
>> Department of Space, Earth and Environment
>> SE-412 96 Gothenburg, Sweden
>> Email: jana.mend...@chalmers.se <mailto:jana.mend...@chalmers.se>
>> Phone : +46 (0)31 772 1883
>> =====================================================================
>> _______________________________________________
>> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
