Hi Patrick It was the Frequency retrieval called using FFIT and not a 'species'. I didn't think about the fact that this was also a retrieval quantity... The problem was that I had set Q.FFIT.DF to zero. Thank you for your help!
Am 30.09.2011 um 13:05 schrieb Patrick Eriksson: > Hi Rolf, > > Can you check which retrieval quantity that generates the NaNs? That is, what > retrieval variable that correspinds to column 61. > > You can do that checking which row in R.ji that contains 61, and then looking > into the corresponding array element in R.jq. jq contains text strings that > give the information. > > Bye, > > Patrick > > > > > On 09/30/2011 12:12 PM, Rolf Rüfenacht wrote: >> Dear qpack users >> >> I get an error because of NaNs when running qpack2.m when attempting to >> do a retrieval. The forward model with the same settings works fine. >> The error occurs on line 119 when calling oem. In the first iteration of >> the while loop between line 561 and 608 in oem.m I get a column of NaN's >> in column 61 out of 65 of J when it is calculated using calc_y_and_j( >> comfun, Q, R, O, xnorm, x, iter );. All the other columns look fine. >> This NaN's then propagate into x when it is updated on line 594. In the >> next iteration an error is produced because of the NaN's in x. >> >> I don't understand why these NaN entries come into J? >> >> When looking at the apriori it appears that the entries for xa to which >> x is set for the first iteration are ==0 for the entries 61 to 65 and >> ~=0 for all other entries. Could that be related to the NaN problem? >> I only use midlatitude-winter xml files for O3, H20, N2 and O2 a >> prioris. Only O3 was retrieved in this run. >> >> Thank you for any suggestions >> >> Rolf _______________________________________________ qpack mailing list [email protected] https://www.sat.ltu.se/mailman/listinfo/qpack
