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 > 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
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
--
=
Jana Mendrok, Ph.D. (Researcher)
Chalmers University of Technology
