# [arts-dev] Non-fractional grid positions

`Hi Stefan, Oliver and other interested in this long email,`
```
```
I just made a commit where I try to fix things to make retrievals using grids having length 1 possible. This is very handy in some cases, but causes problems with the interpolation inside arts. For the moment I have solved this by special functions, and this generated quite a bit of code.
```
```
But it could in fact be solved in a general manner. And then also fix other things.
```
```
For running OEM the issue of concern appears when mapping the x vector back to arts' variables. If we use 3D and a length-1 pressure retrieval grid as example, then we end up with a situation that we want to interpolate a Tensor3 having size X(1,nlat,nlon)
```X can be a scaling factor for H2O as indicated in my ChangeLog message

```
In the calculation of the Jacobian, I use the grid_pos system to map data from line-of-sights to the retrieval grids, and I once made some function that gives a correct grid position for length-1 retrieval grids. That is, the grid position is set to
```0 0 1
It works in fact to calculate interpolation weights for this case.

```
On the other hand, you can not apply the interp functions, as these functions always include idx+1, even if fd[0]=0. That is, there is a blind summation for the values inside the grid range, even if some values will get weight 0. My new functions could be removed if the interp functions noticed when it is unnecessary to involve idx+1.
```
This would also solve:

```
Now it is not possible to set the grid position to the end grid point. That is,
```
n-1 0 1

```
as idx+1 is then an invalid index. This generated extra code in the ppath part. For basically all observations there is a ppath point exactly at the uppermost pressure level.
```
```
Quite a lot of our interpolations could be avoided. As retrieval grids normally are sub-sets of the forward model grids (and is the recommended choice for numerical accuracy), there is a lot of interpolation that in fact is not interpolation (i.e. points of new and old grid are the same). And is this not also the case for interpolation of absorption lookup tables? The normal case should be that the pressure grid of the lookup table equals p_grid. As we here apply polynomial interpolation, a lot of calculations could be saved by identifying when fd[0]=0. (or is there special code for abs_lookup?)
```

```
The question is how to add this without making the general interpolation slower. I assume that a boolean in the grid_pos structure could help, that is true if fd[0] can be treated to be exactly zero. If we call this new field nonfrac, the green 2D interpolation could like this
```
tia = 0;
for ( Index r=0; r<tr.nonfrac?1:2; ++r )
for ( Index c=0; c<tc.nonfrac?1:2; ++c )
{
tia += a.get(tr.idx+r,tc.idx+c) * itw.get(ir,ic,r*2+c);
}
}

```
(cf. interpolation.cc line 2580. Note that I had to add some temporary asserts to make sure that my special code is OK.)
```
```
This has the drawback that r*2+c is more costly than ++iti (as in the present solution), but we could still gain on average. Another option would be that a similar thing is done when calculating the interpolation weights, i.e. the number of weights is smaller when nonfrac is true. The weights should be ordered in such way that ++iti will work. And we should then really gain on average!?
```

```
And now realize that this bool would have saved me a lot of headache in the ppath_step part. There are a lot of checks if fd[0] is effectively zero (which it is for the end points of each step). Introducing the flag would allow me to clean up this.
```

```
What do you say? Comments? Or an even better solution? If you don't follow, ask or let's discuss next Friday.
```
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
```