Hi Richard,

It's nice that you are trying to use these methods. As far as I know, you are the first using the methods not using Qpack.

I will have a look at the jacobianAdd methods and try to explain more clearly how many x-elements that are generated by each method.

It seems reasonable that you should get information on involved sizes if Jacobian and Sx parts do not match. I assume Simon will look at it (but he is taking a course this week, working on a ESA study, ..., so it can take some time)



On 2019-01-21 15:07, Richard Larsson wrote:

(This is mainly a question to Simon and Patrick but the dev-list exists so I am using it.)

I have been trying out the retrievalAdd* functions for the systems we have in Gottingen.  One of the most difficult bit is to figure out is how to complete the retrieval setups without running loops around the errors being reported.  I might be a complete idiot about this, but the documentation and error reporting by ARTS seems far from good here.

I have identified two problems:

1)  The covmat-block size requested by the add-functions are not reported in the documentation of said functions.

2)  The error when either retrievalDefClose or the individual retrievalAdd* functions fail is not detailed enough to even hint at the problem, it simply states that the covmat has the wrong size.

I have suggestions below for how I would fix it if I knew the functions well enough.  Ignore these if you want to, but please try to address the poor documentation and error somehow.

For the first, each individual retrievalAdd* function would have to be addressed.  Some examples of problematic functions: jacobianAddFreqShift reports it may be "constant in time", which means covmat _block is 1-by-1, and jacobianAddSinefit reports "one sine and one cosine term" per period-length, or a 2-by-2 uncorrelated covmat_block for every period length.  These also sound like reasonable sizes, given that they both are just used as baseline-fit for sensor phenomenon (so there is no p_grid dependency).  However, of course they fail when you use these covmat-block-sizes.  This means there is an error in the method documentation.  To fix this, I suggest the increase in size of the Jacobian matrix is written clearly in each of the jacobianAdd* descriptions.  The same apply for their retrievalAdd* cousins, where the size of the covmat-block should be spelled out.

The second point seems even easier to address.  If the internal check fails, please report how.  If I see: "I was expecting the Jacobian matrix to be 4001 x 510 and the covariance matrix to be 510 X 510. Instead, the covariance matrix is 498 X 498", this means that I can begin to guess at the error.  Presently, the somewhat nonsensical "Matrix in covmat_block is inconsistent with the retrieval grids" is used instead, which does not help identify the cause of the problem at all.

With hope,

arts_dev.mi mailing list

arts_dev.mi mailing list

Reply via email to