I probably need to lay out my design at this point. At the moment, I ask
the dynamics for the following information:

h3.  total number of columns in dynamics computational grid
  call get_horiz_grid_cnt_d(ngcols_d)

Here I assume that the dynamics indexing scheme is 1:ngcols_d

h3.  latitude and longitude (in radians) of a given column, and a flag
h3.  indicating whether this column will be passed to the physics
  call get_horiz_grid_coord_d(i,use_col,clat_d,clon_d)

If there are holes in the range 1:ngcols_d, setting use_col to .false.
means that I won't look at the clat_d and clon_d values.
From this I build a physics view of the computational grid,
identifying the number of unique latitudes and longitudes,
and reordering the columns (for which use_col == .true.)
east to west, south to north. Given that this ordering is what
all of the surface models seem to expect (see logic, for example,
in ocn_comp_mct), I propose that this be the external view
of the CAM grid.
Given the number of times that global longitude and latitude indices
are still used in the physics, I propose to retain these, but they
now just point into the list of unique latitudes and unique longitudes,are do not reference anything in the dynamics commap.
We can clean up some of this later.
This approach appears to be sufficient in cleaning up all of the
surface model interfaces, with the possible exception of the
following code in ccsm_msg.F90:

   !
   ! load in the lat, lon, area, mask, and compute gridpoint numbers for
   ! points on this processor
   !
   n=0
   startpoint = 0
   do j=1,plat
      do i=1,nlon(j)
         if(get_chunk_owner_p(i,j) .eq. iam) then
            n=n+1
            sbuf(n,cpl_fields_grid_lon) = clondeg(i,j)
            sbuf(n,cpl_fields_grid_lat) = clatdeg(i,j)
            sbuf(n,cpl_fields_grid_area) = area(i,j)
            sbuf(n,cpl_fields_grid_mask) = real(mask(i,j),r8)
            sbuf(n,cpl_fields_grid_index) = startpoint + i
         endif
      enddo
      startpoint = startpoint + nlon(j)
   enddo

I can deal with everything except the area and mask arrays.
Are there HOMME equivalents to these? Should I define
these in the physics, and eliminate any dependencies on the
dycore?
Thanks.
Pat
The interfaces that you show are fine and the physics_view is fine, but I think that at least initially we would like an option in which no reordering occurs. Is this consistant with the -1 loadbalancing option?
Global latitude and longitude are almost completely eliminated from the physics. Outstanding issues are noted in Use of plon and plat in physics and control

The actual ordering and the index ordering are independent. I am planning on phys_loadbalance == -1 to make chunks and blocks identical, except that columns not being shared (use_col == .false.) will not be copied.
+
Back to Implement HOMME dycore

  • No labels