Hi Jonas, Hi Simon,
@Jonas: This is just a test case, but I want to mention that you should
not expect accurate results using it. The f_grid has a general spacing
of 400kHz around the line center and that's too coarse for good results.
Maybe clear for you, but a comment just in case ...
1) If the frequency grid f_grid is very narrow at certain points (~< 100
kHz, intentionally or by mistake with VectorInsertGridPoints) the
sensor.cc throws an error:
Indeed, this made the test to fail. Going to 102 points the f_grid has a
spacing of just 40 Hz between some points and I then assumed that there
was some numerical issue. This is probably a set up that shall be
avoided, but it seems that ARTS handles it. In the end the fix turned
out to be this (in inversion_iterate_agenda):
atmfields_checkedCalc( negative_vmr_ok = 1 )
That is, the change in f_grid happen to generate some negative VMR in
the first iteration. In inversions you could need accept this.
By the way, the test case works with LM iteration even without allowing
negative VMR. That should prove that ARTS handles the case in acceptable
manner. That said, I have not checked the final result. Feel free to do
that.
@Simon: It took me some time to track this down as the error happened
inside inversion_iterate_agenda. OEM does not display that error and it
is then very difficult to understand what's going on. This must be fixed
in some way. Can't OEM just simply display the error message?
Or rather just throw the error. It is not useful to continue if you have
an error of this type. In this case, you instead get an error from
another method that is just distracting.
(We can discuss when we meet, if needed)
Bye,
Patrick
_______________________________________________
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
