[MITgcm-support] netcdf with curvilinear grid

[Martin Losch]

Hi again,

in pkg/mnc/mnc_cw_cvars.F I have replaced lines like:
         cv_start(1) = 1
         cv_count(1) = sNx
         DO i = cv_start(1),cv_count(1)
#ifdef ALLOW_EXCH2
           rtmp(i) = xtmin + i
#else
           rtmp(i) = xC(i,1,bi,bj)
#endif
         ENDDO
with
         cv_start(1) = 1
         cv_count(1) = sNx
	IF (usingCurvilinearGrid) THEN
          DO i = cv_start(1),cv_count(1)
           rtmp(i) = xtmin + i
          ENDDO
         ELSE
          DO i = cv_start(1),cv_count(1)
           rtmp(i) = xC(i,1,bi,bj)
          ENDDO
         ENDIF
which gives me the expected behavior of ncview and gluemnc (and also  
meaning full "coordinate variables", that is the grid indices, for a  
general curvilinear grid). Now is that check-inable? Before, only  
runs with EXCH2 where treated that way, implicitly assuming that with  
EXCH2 you'd always be usingCurvilinearGrid=.true. Is it possible to  
use EXCH2 with usingCurvilinearGrid=.false.? If so, will the above be  
wrong? Should I rather add an extra #ifdef ALLOW_EXCH2 block?

Martin

>
On 31 Jan 2008, at 12:26, Martin Losch wrote:

> Hi Ed and others,
>
> sorry to hear that I kept you up so long. That was not my  
> intention. Hope you are asleep now and others pick up for you (o:
>
> And now I have to tell you, that the problem is not really in the  
> netcdf files. The problem is that my screwy configuration with a  
> curvilinear grid does not have "proper" coordinate variables (in  
> netcdf speak), so that programs like ncview or gluemnc, that use  
> coordinate variables to display/arrange individual tiles give funny  
> results.
>
> I would suggest to modify mnc, so that in the case of  
> "usingCurviLinearGrid=.TRUE." (and without exch2), the coordinate  
> variables X and Y become simply the grid indices, as it is done for  
> the cube sphere/llc configurations (which do use exch2). Could you  
> point me to the places/files where this should be done and I'll try  
> to do that.
>
> Martin
>
>
> On 31 Jan 2008, at 10:08, Ed Hill wrote:
>
>> On Thu, 31 Jan 2008 08:34:30 +0100 Martin Losch wrote:
>>>
>>> where in the jungle of mnc can I find a clue of what's happening,
>>> why for one tile/cpu, the j-ordering is one way and for the other
>>> it's reversed, what variables control that and where do they get
>>> their information from, so I can try to hunt this problem down.
>>
>>
>> Hi Martin,
>>
>> Its 4am here.  I've already spent a long day coding and then looked
>> through MNC and MITgcm files just because you asked so *very*
>> politely.
>>
>> I don't understand your problem.  Perhaps its lack of sleep.  But  
>> here
>> are some observations:
>>
>>  0) The "gridfiles.tar" you sent is not a complete setup.  I
>>     don't have the foggiest idea what topology (EXCH1 or EXCH2)
>>     you are trying to use since you very helpfully omitted all
>>     the input files or code that specify that information.
>>
>>  1) When you think about the grids keep in mind that MNC does
>>     not (anywhere!) "flip" or permute the grid quantities
>>     during either reads or writes to the netcdf files.  The
>>     netcdf files always have the same "orientation" in memory
>>     within MITgcm as they do on disk -- just the addition
>>     or removal of points around the halo regions.
>>
>>     The only thing like "flipping" that MNC does is the storage
>>     of the tile edge-edge coincidence information as provided by
>>     either "EXCH1" or EXCH2.  You can use:
>>
>>       cd pkg/mnc
>>       grep -i exch *.F
>>
>>     to see where these occur within MNC.  And note that this
>>     "flipping" does not permute anything *within* the per-tile
>>     files.  It just specifies how the tiles are "sewn" together.
>>
>>  2) Have you looked at the code in the following files:
>>
>>       model/src/ini_curvilinear_grid.F
>>       pkg/exch2/w2_e2setup.F  (if using EXCH2)
>>
>>     and convinced yourself that things have the same order within
>>     the *.mitgrid files that the code expects?  Its a very good
>>     place to start.
>>
>>
>> Ed
>>
>> -- 
>> Edward H. Hill III, PhD  |  ed at eh3.com  |  http://eh3.com/
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support