[MITgcm-devel] exf_interp and grib data

[Martin Losch]

Yes, all in global_with_exf/input

Martin

> On 13 Mar 2015, at 14:45, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
> 
> Hi Martin,
> 
> You can go for it. The new wind-stress file could stay in
> global_with_exf/input 
> does not need to be in tutorial_global_oce_latlon/input, right ?
> 
> Cheers,
> Jean-Michel
> 
> On Thu, Mar 12, 2015 at 05:02:47PM +0100, Martin Losch wrote:
>> I think I found a way to do this. Since it is not so difficult after all, I’d like to check in the code. 
>> 
>> We could test this with some (maybe just one?) of the files in global_with_exf, which is the only experiment that tests the interpolation code anyway. 
>> I can get perfect agreement with “trenberth_taux.bin" flipped (I call this now trenberth_taux.flipped”), and
>> ustress_lat0    = 78.,
>> ustress_lat_inc = 39*-4.,
>> 
>> The only problem with this test is, that it will increase the size of the MITgcm download by the size of trenberth_taux.bin (well, 169kB). What do you think?
>> 
>> Martin
>> 
>> 
>> 
>>> On 12 Mar 2015, at 15:26, Martin Losch <Martin.Losch at awi.de> wrote:
>>> 
>>> Hi Jean-Michel,
>>> 
>>> I tried to add code for the case of y_in(0)>y_in(nyIn+1) (or lat_inc<0), but wasn’t successful. 
>>> I guess I need to understand this code first, but before I seriously try, do you think it’s worth it?
>>> 
>>> Is this the only place where this assumption is made? Or maybe there’s something exf_interpolate.F as well?
>>> 
>>> Martin
>>> 
>>>> On 12 Mar 2015, at 14:15, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
>>>> 
>>>> Hi Martin,
>>>> 
>>>> I did not check carefully, but I vagely remember that exf-interp assumes
>>>> lat_inc > 0 (& lon_inc > 0). For instance, exf_interp.F, lines 350-357:
>>>>         IF ( w_ind(i,j).GT.s_ind(i,j)+1 ) THEN
>>>>          k = NINT( (s_ind(i,j)+w_ind(i,j))*0.5 )
>>>>          IF ( yG(i,j,bi,bj) .LT. y_in(k) ) THEN
>>>>            w_ind(i,j) = k
>>>>          ELSE
>>>>            s_ind(i,j) = k
>>>>          ENDIF
>>>>         ENDIF
>>>> In theory, should be possible to (re-)write the code for the case
>>>> of negative increment but, except if I am wrong, this is not presently the case.
>>>> 
>>>> Cheers,
>>>> Jean-Michel
>>>> 
>>>> On Thu, Mar 12, 2015 at 11:18:41AM +0100, Martin Losch wrote:
>>>>> Hi there
>>>>> 
>>>>> I am trying to convert (on the fly) atmospheric data in grib format into ieee-be so that I can use exf (exf_interp) to read it.
>>>>> The grb data seems to put the index (i,j) = (1,1) at the top left (NW) corner, whereas we expect (i,j)=(1,1) to be at the bottom right (SW) corner of the gridded data field. For technical reasons, it would be simpler to not have to flip the forcing fields (I would like to use wgrib <http://www.cpc.ncep.noaa.gov/products/wesley/wgrib.html>, which can produce ieee-be fields from grib data, but doesn’t seem to be able to do the N to S-flip), so that my data.exf entry would look like this:
>>>>> 
>>>>> ${var}_lat0 = 78,
>>>>> ${var}_lat_inc = 39*-4.,
>>>>> 
>>>>> instead of 
>>>>> ${var}_lat0 = -78,
>>>>> ${var}_lat_inc = 39*4.,
>>>>> 
>>>>> Appart from the fact, that the routine exf_interp checks if the forcing grid “encompasses” the model grid (which it does technically), and this fails (because the check also expects lat0 to be the southern-most latitude), can exf_interp handle this situation properly? (a simple test with global_with_exf suggests, that it does not, but why?)
>>>>> 
>>>>> Martin
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> MITgcm-devel mailing list
>>>>> MITgcm-devel at mitgcm.org
>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>>> 
>>>> _______________________________________________
>>>> MITgcm-devel mailing list
>>>> MITgcm-devel at mitgcm.org
>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>> 
>>> 
>>> _______________________________________________
>>> MITgcm-devel mailing list
>>> MITgcm-devel at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>> 
>> 
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel