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)
Bye,
Patrick
On 2019-01-21 15:07, Richard Larsson wrote:
Hi,
(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,
//Richard
_______________________________________________
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
_______________________________________________
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
