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)



arts_users.mi mailing list

Reply via email to