Richard,
Now you are a bit all over the place. Yes of course, things can be
handled in a more nice way if we introduce new features.
ARTS is almost 20 years! When we started ARTS the aim was in fact to use
as few "groups" as possible. And I would say that we kept that rule a
long time, but lately things have changed. You have added some new
groups during the last years and OEM resulted in some other new ones.
Before we were picky about that each group could be imported and
exported to files, and could be printed to screen. I don't know if this
is true for all newer groups.
I don't say that the new groups are bad. For sure we needed a special
group for covariance matrices, as example. But as usual I would prefer
that we have a clear strategy for the future. And there should be
documentation.
I am prepared to discuss this, but not by email. It just takes too much
time, and these email discussions tend to become a moving target. But I
could try to find a time for a video/tele conf if there is a general
feeling that we should add more groups now or in a close future.
Bye,
Patrick
On 2019-03-26 11:51, Richard Larsson wrote:
Hi Patrick,
Den mån 25 mars 2019 kl 19:47 skrev Patrick Eriksson
<patrick.eriks...@chalmers.se <mailto:patrick.eriks...@chalmers.se>>:
Hi Richard,
I can agree on that this is not always critical for efficiency as long
as the check is a simple comparison. But some checks are much more
demanding. For example, the altitudes in z_field should be strictly
increasing. If you have a large 3D atmosphere, it will be very
costly to
repeat this check for every single ppath calculation. And should
this be
checked also in other places where z_field is used? For example, if you
use iyIndependentBeamApproximation you will repeat the check as also
the
DISORT and RT4 methods should check this, as they can be called without
providing a ppath.
If a bad z_field can cause an assert today, then it has to be checked
every-time it is accessed.
This problem seems simply to be a quick and somewhat bad original
design (hindsight is 20/20, and all that). To start with, if it has to
be structured, then z_field is not a field. It is as much a grid as
pressure, so the name needs to change.
And since we have so many grids that demands a certain structure, i.e.,
increasing or decreasing values along some axis but perhaps not all,
then why are these Tensors and Vectors that are inherently
unstructured? They could be classes of some Grid or StructuredGrid
types. You can easily design a test in such a class that makes sure the
structure is good after every access that can change a value. Some
special access functions, like logspace and linspace, and
HSE-regridding, might have to added to not trigger the check at a bad
time, but not many.
Since, I presume, iyIndependentBeamApproximation only takes "const
Tensor3& z_field" at this point, the current z_field cannot change its
values inside the function. However, since it is possible that the
z_field in iyIndependentBeamApproximation is not the same as the z_field
when ppath was generated, the size of z_field and ppath both has to
checked in iyIndependentBeamApproximation and other iy-functions.
However, to repeat: If a bad z_field can cause an assert today, then it
has to be checked every-time it is accessed.
Further, I don't follow what strategy you propose. The discussion
around
planck indicated that you wanted the checks as far down as possible.
But
the last email seems to indicate that you also want checks higher up,
e.g. before entering interpolation. I assume we don't want checks on
every level. So we need to be clear about at what level the checks
shall
be placed. If not, everybody will be lazy and hope that a check
somewhere else catches the problem.
There were asserts in the physics_funcs.cc functions. Asserts that were
triggered. So I changed them to throw-catch.
I am simply saying that every function needs to be sure it cannot
trigger any asserts. Using some global magical Index is not enough to
ensure that.
A Numeric that is not allowed to be outside a certain domain is a
runtime or domain error and not an assert. You either throw such errors
in physics_funcs.cc, you make every function that takes t_field and
rtp_temperature check that they are correct, or you create a special
class just for temperature that enforces a positive value. The first is
easier.
In any case, it should be easier to provide informative error messages
if problems are identified early on. That is, easier to pinpoint the
reason to the problem.
I agree, but not by the magic that is *_checkedCalc, since it does not
guarantee a single thing once in another function.
With hope,
//Richard
_______________________________________________
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
