# Regularly-spaced coordinates

gabor@hermes.chpc.utexas.edu
Wed, 25 Mar 92 13:08:50 CST

```Hi Folks,

hjenter@stress.er.usgs.gov (Harry Jenter ) writes:

>                        - Text deleted -
> I think that netCDF does not require this assumption to be made.  It is
> just more intuitive for storing rectangular or, more generally,
> quadrilateral grids, without introducing one's own conventions. (Note:
> I stick to the 2-d grid analogy for the rest of this post.  The
> arguments can be extended to 3 or more dimensions, but I don't know the
> words for "equivalent of quadrilateral" in 3 or more dimensions.)
> There seem to be no assumptions regarding grid shape.  There are also
> seem to be no conventions regarding grid shape.

I agree to some extent. netCDF said nothing about the rectangularity
of the grid because it looked obvious and intuitive. That was the
assumption itself: we did not even mention that the grid can be non-
rectangular, we just followed the common sense and sticked to the
rectangular grid. When you say:

example {
dimensions:
x  = 4;
y  = 4;
variables:
float   temp( x, y  );
int     x(x);
int     y(y);
data:
x     = x1,x2,x3,x4;
y     = y1,y2,y3,y4;
temp  = ... ;
}

Variable 'temp' is automatically considered as given over a
rectangular grid:

|     |        |   |
|     |        |   |
y1---|-----|--------|---|-----------------
|     |        |   |
|     |        |   |
|     |        |   |
y2---|-----|--------|---|-----------------
|     |        |   |
y3---|-----|--------|---|-----------------
y5---|-----|--------|---|-----------------
x1    x2       x3  x4

I think this is a stone-hard assumption made in the definition of
netCDF. Surely very intuitive, that is why it became a part of the
definiton. But originally, it used to be just a restrictive
assumption, purposely limiting the complexity of the grid.

>
> I think, however, that the issue of storing non-quadrilateral grids is
> a more difficult issue to address than the regularly-spaced-coordinate
> issue. In fact, it is, in a sense, the opposite problem.

It's correct: it is really the opposite. I wanted to point out that
rectangular grid is just a special case -however, very obvious and
intuitive- of the general polygonal grid. I do think non-rectangular
quadrilateral and triangular grids are very important, too. I'm just
saying that much unfinished work seems to be left behind our back in
the opposite direction, too.

> For regularly-spaced coordinates, one can reduce the information stored in
> a netCDF file relative to the "intuitive" method of storing a 1-d array for
> each coordinate, and still can reproduce the grid.  For non-quadrilateral
> grids or even quadrilateral-but-not-rectangular grids, one must
> increase the amount of information stored in the netCDF file in order
> what nodes are connected must be stored.  For curvilinear grids, the
> coordinate arrays must have more than one dimension.
> 			- Text deleted -

Yes, it is perfectly true. At a higher conceptual level the
believe the isssue is not only to reduce the size of the storage but
to increase its functionality, too. In this particular case: we need
more complex grids than the rectangular.
I do not want the user to specify his/her regular data always in the
most general way; the user must be able to specify the grid at the
lowest possible level in order to keep the storage size and processing
time at the minimum.
I just propose we streighten out more than the issue of the
regularly spaced grids. Why don`t we want the whole pie: the concept
for storage of grids of different complexity and mathematical
generality. I could imagine something like this:

general grids ----> quadrilateral ---> rectangular ---> reqularly spaced
|                                        /  |   \
|--> triangular                         /   |    \
|                                   linear  |   other important
|--> other                             logarithmical

Do not be afraid of (mandatory?) attributes and adequate defaulting
while it is designed consistently. We just need correct definition
preventing future exceptions and additional assumptions. It can be
done with you, folks, for sure!

Cheers!

Gabor Fichtinger

Scientific Visualization Group,
Center for High Performance Computing
The University of Texas System
Balcones Research Center, 1.154 CMS
10100 Burnet Road, Austin, TX, 78758-4497
Ph.  : (512) 471 2409
Ph.  : 1-800-262-2472/2409 (toll free)
Fax  : (512) 471 2445
Email: gabor@chpc.utexas.edu
__o
__o             -\<,
-\<,  __________O / O
___________O / O
```