Automated support for curvilinear variables (OLD VERSION)

[karlmsmith]

Reported by steven.c.hankin on 19 Dec 2003 18:17 UTC

Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/751

[karlmsmith]

Comment by steven.c.hankin on 19 Dec 2003 18:27 UTC Preliminary ideas for automating curvilinear (CF) support in Ferret:

New concepts: curvilinear grids ? grids may have a dual description?possessing both rectilinear and curvilinear X and Y coordinates

context cluster ? multiple consecutive elements on the context stack may be flagged as a ?cluster?

Syntax: To define a curvilinear grid add new qualifiers DEFINE GRID /xcurv=/ycurv= If the curvilinear coordinates (dependent variables themselves) depend upon Z or T they must agree with the Z and T axes of the grid [requires new COMMON grid variables curv_x_var, curv_x_cat, curv_y_vay, curv_y_cat] [create new INTEGER FUNCTION ITS_CURVILINEAR(grid) ]

Similarly SET GRID

For the user to invoke automated curvilinear behavior (s)he uses this syntax: -- add [CURVILINEAR] in the qualifiers of a variable -- add /CURVILINEAR to the command qualifier -- use SET MODE CURVILINEAR e.g. "CONTOUR temperature, xcoords, ycoords" is equivalent to "CONTOUR/CURVILINEAR temperature" or "CONTOUR temperature[CURVILINEAR]"

======================

Source code logic

• the TMAP library (the USE command) must infer curvilinear grids based upon CF conventions. Significant enhancements needed to those routines to create curvilinear grids.

• when automatic curvilinear behavior is invoked (using syntaxes above)

  • GET_CONTEXT_MODS sets Boolean cx_its_curvilinear
  • in INTERP_STACK when cx_its_curvilinear is encountered a stack operation is invoked (a call to IS_STRIP) to inform the context stack that it must get the variable followed by its X,Y coordinates
  • the three stack elements are flagged as a ?context cluster? by setting cx_cluster_size(cx) = 3 [dflt=-111], cx_cluster_type(cx)=pcluster_curvilinear [dflt=-111]

• all operations that consume variables from the cx stack must be altered to consume context clusters

(context clusters may later prove useful for vector pairs and triples and for complex variable supports)

[karlmsmith]

Comment by @AnsleyManke on 19 Dec 2003 19:22 UTC Moving to "Ferret Tasks" product, and add Ansley to the CC list.

[karlmsmith]

Comment by @AnsleyManke on 24 Sep 2004 19:00 UTC Further comments SH 9/24/2004

It's probably time that we should should start an ongoing chat theme on steps we'll need to take to achieve automated handling of curvilinear variables in Ferret. A start on that theme here ... The discussion below attempts to outline a strategy for easily performing automated regridding of curvilinear vars to a rectilinear representation.

[aside: it is a constant hassle in Ferret that there is not a clean syntax for passing a grid definition to a function. Instead you have to pass a variable that is defined on that grid. Maybe we should consider creating a new syntax like "g=" as in foo = FUNCTION(v1, v2, g=grid_or_varname) that would pass a grid definition to a function .... It wouldn't be terribly hard to do this ... a separate discussion.]

Anyway ... suppose that there were an internal function in Ferret called (say)

CURV_REGRID_MAPPING(g=curvilinear_grid, g=rectilinear_grid)

[I'm guessing at the precise description of this function -- you know the correct characterization] The output of this function inherits the X Y axes of rectilinear_grid and had a 2 point T axis. The T axis allows the index mapping and weights to be included in a single variable.

And you already have a companion function (something like this) CURV_REGRID(my_curv_var, curv_map[i=lo:hi, j=lo:hi]) that computes the regridded result, given the input field and the mapping variable.

Now imagine a new command yes? SET GRID/rectilinear=/mapname=my_map_var

This command associates a curvilinear grid with its rectilinear representation. The internal effect of this command would be 1. store the rectilinear grid name as a part of the definition of the curvilinear grid 2. store the variable name "my_map_var" as a part of the definition of the curvilinear grid 3. create a new variable with the definition 4. LET my_map_var = CURV_REGRID_MAPPING(g=curvilinear_grid, g=rectilinear_grid) (probably) to compute and flag as memory-permanent the variable my_map_var over its full domain -- see note at end And imagine that a new stack operation class was created (see either "isact_class_" or "isact_" for reference ... I can't recall) called isact_class_curv_regrid. This stack operation handles the steps to automatically create the rectilinear representation of a curvilinear variable. Now, currently when Ferret needs to perform an operation on a rectilinear variable like "vrect[x=lo:hi`@ave`, y=lo:hi`@ave`]" what it does is 1. puts a request for the operation "x=lo:hi`@ave`, y=lo:hi`@ave`" onto the "IS" stack (IS == "interpretation stack") as an isact_average 2. requests "vrect[x=lo:hi, y=lo:hi]" The analog to this for a curvilinear variable would be that whenever Ferret needs to perform an operation like "vcurv[x=lo:hi`@ave`, y=lo:hi`@ave`]" it will 1. [no change from above] put a request for the operation "x=lo:hi`@ave`, y=lo:hi`@ave`" onto the "IS" stack 2. put a request for the rectilinear representation of "vrect[x=lo:hi, y=lo:hi]" onto the stack flagging the activity as isact_class_curv_regrid The job of the isact_curv_regrid will be to perform 3 phases 1. request the needed subset of my_map_var 2. request the needed subset of vcurv (the algorithm to determine this will be important for good performance on large curvilinear grids) 3. perform the curvilinear regridding notes: * need to think of how the calculated "my_map_var can be saved and restored from session to session maybe SET GRID/rect=.../mapname=.../LOAD[=filename] where "/LOAD" forces either an immediate computation or an immediate read from the named file. Just initial sketches here for discussion ...

[karlmsmith]

Comment by @AnsleyManke on 5 Nov 2004 19:20 UTC Changing Component of bugs in "Ferret Tasks" from All to Main

[karlmsmith]

Comment by steven.c.hankin on 20 Jan 2009 18:19 UTC The preceding entries may be more thorough and better thought out than what follows. They go a-way back to 2003 and 2004. But the ideas that follow are likely to be simpler and are based upon new knowledge of plans to incorporate fregrid logic, which will simplify things (we hope).

'''curvilinear grid definitions''' o may be as simple as adding 4 variables to the definition of a grid (indexed by the same index as the current grid) -- xcurv, ycurv, xcurv_edges, ycurv_edges -- that point to the curvilinear coordinate variables o The code behind SET DATA needs to locate and set these variables.[[BR]]

o During the get_grid phase of variable definitions (dynamic grids) these pointers must also be maintained

'''automated curvilinear plotting''' (a small thing) o add SHADE/CURV and CONTOUR/CURV to automate the 3-argument curvilinear plots. After the get_grid phase is completed for a /CURVILINEAR plot, push the X and Y coordinate variables (or edges if available) onto the stack, reducing this to a standard 3-argument plot thereafter.

'''suggested API for fregrid functionality''' (initial thoughts) o CREATE/REGRID_MAP=filename source_var, target_var o creates the index map using fregrid calls o CREATE/GRIDSPEC=filename var o create a gridspec description (and associated geometry, contacts, etc.) from a standard curvilinear or rectilinear grid

[karlmsmith]

Modified by steven.c.hankin on 20 Feb 2013 19:05 UTC

[karlmsmith]

Modified by steven.c.hankin on 20 Feb 2013 19:52 UTC