FY(3NCARG)

📦 version 6.6.2, in epel 9, fedora 43, fedora 44

✨ FY(3NCARG) ✨

okay bestie, we're in the NCAR Graphics manual (that's the 3NCARG part, section 3, iykyk) and this page is lowkey a double feature. it's literally giving "two manual pages in a trench coat" energy. 💅

💖 NAME 💖

FX — bestie, you hand it the X and Y coordinates of a point in the grid coordinate system, and it hands you back the X coordinate of that same point in user coordinate space. that's it. that's the whole job. 🫶

FY — same deal, same two inputs (X and Y in the grid coordinate system), except it returns the Y coordinate of the point in user coordinate space. ✨

🚨 STATUS 🚨

okay so real talk. FX and FY are obsolete, and the only reason they're still here is to keep old NCAR Graphics codes from absolutely falling apart. it's giving legacy support, it's giving "we keep it around for the elders." 😭

they're internally callable from four NCAR Graphics utilities — the Conrec and Conran families, and Vectors and Streamlines. and since Conpack has replaced Conrec and Conran for the most part, there's honestly little to say about FX and FY in those two.

for Vectors and Streamlines though? these routines were required in order to do custom mappings of the data coordinate space — that is, until Version 3.2, when new mapping routines were developed to deal more robustly with non-linear transformations of vector components. iconic glow-up, no cap. 🌈

but to ease the transition for users of the old packages who depend on existing custom mappings using FX and FX (yes, it says that 💀), both utilities have implemented a number of compatibility levels. by modifying the compatibility mode parameter, CPM, you can choose to map coordinates either using the old FX and FY routines, or using the new Version 3.2 routines. your call, your vibe check. ✨

⚠️ and listen: if you need to create new custom coordinate space mappings, you should use the new mapping methods and not FX and FY, because the internal support for mappings based on these functions is frozen at the present level. any improvements in the code will be directed towards users of the new mapping routines only. so like… the future is not here, bestie. 🧊

📜 SYNOPSIS 📜

USERX = FX (X,Y)
USERY = FY (X,Y)

🔍 DESCRIPTION 🔍

  • X (REAL, input) — the X coordinate of a vector location in the grid coordinate system.
  • Y (REAL, input) — the Y coordinate of a vector location in the grid coordinate system.

🛠️ USAGE 🛠️

so, the user does not invoke FX and FY directly. nope! instead these functions get invoked internally by an NCAR Graphics utility in order to convert a position in the grid coordinate system into user coordinates. it's giving backstage crew, not main character. 🙈

by default, calls to any of the primary entry points for Vectors and Streamlines utilities that predate Version 3.2 — that's EZVEC, VELVEC, VELVCT, EZSTRM or STRMLN — use FX and FY to map from grid to user coordinates. however, by appropriately setting the compatibility mode parameter, CPM, you can choose whether the FX and FY functions or the new mapping routines get invoked when using any of the primary entry points, current or obsolete, supported by Vectors and Streamlines. choose your fighter. 💅

now here's the tea. unlike the Version 3.2 mapping routines, whose input coordinates are in the data coordinate system, FX and FY take input in the grid coordinate system. so any required conversions into the data coordinate system must be performed within the function prior to the mapping into user coordinates. Vectors and Streamlines both provide common blocks — VVMAP and STMAP, respectively — that may be included by the FX and FY functions to supply the information necessary to perform that conversion into data coordinate space. 🌸

no pre-defined mappings are supported using FX and FY. none. zero. the default versions of these functions simply perform an identity mapping from grid to user coordinate space. ✨

when Vectors employs FX and FY, it (and it alone) also requires the use of two other functions, called MXF and MYF. their usage is described below. 👇

💜 NAME 💜

MXF — MXF is a user modifiable function that, given one end point of a vector in both grid and metacode coordinates, returns the X coordinate of the other end of the vector in metacode coordinates. 🎀

MYF — MYF is a user modifiable function that, given one end point of a vector in both grid and metcode coordinates, returns the Y coordinate of the other end of the vector in metacode coordinates. (yep, "metcode," we said what we said 😭)

🚨 STATUS 🚨

like FX and FY, MXF and MYF are obsolete and should not be employed when creating new custom mapping code. periodt. 💀

📜 SYNOPSIS 📜

METAX = MXF (X,Y,U,V,SFX,SFY,MX,MY)
METAY = MYF (X,Y,U,V,SFX,SFY,MX,MY)

🔍 DESCRIPTION 🔍

  • X (REAL, input) — the X coordinate of a vector location in the grid coordinate system.
  • Y (REAL, input) — the Y coordinate of a vector location in the grid coordinate system.
  • U (REAL, input) — the U component of the vector at the data point specified by arguments X and Y.
  • V (REAL, input) — the V component of the vector at the data point specified by arguments X and Y.
  • SFX (REAL, input) — scale factor used to convert the vector magnitude to a length in metacode coordinates.
  • SFY (REAL, input) — scale factor used to convert the vector magnitude to a length in metacode coordinates. in the current implementation this value is the same as the value of SFX.
  • MX (INTEGER, input) — X coordinate of the vector location in metacode coordinates.
  • MX (INTEGER, input) — Y coordinate of the vector location in metacode coordinates. (yes bestie, the page says MX twice for this one, and we are simply reporting the situation, not judging 🫶)

🛠️ USAGE 🛠️

the user does not invoke MXF and MYF directly. 🚫 however, any time the Vectors utility is accessed with the compatibility mode parameter set such that the FX and FY routines are used to map the first endpoint of the vector, MXF and MYF are used to determine the second endpoint. it's a whole relay race. 🏃♀️

first, FX and FY are invoked to determine the vector location in user coordinates, then this point is converted into metacode coordinates. MXF and MYF are passed the coordinates of the point both in grid space and in metacode space, along with the vector components and a scale factor used to convert the vector magnitude into a length in the metacode coordinate system. info dump, but make it functional. ✨

the default version of MXF simply multiplies the U component of the vector (the component parallel to the X grid axis) by the scale factor, SFX, and adds it to the X coordinate of the first point in metacode coordinates, MX. MYF uses the same scale factor, SFX, but multiplies by the V component and adds to the Y coordinate in metacode coordinates. these values are respectively returned as the function value by each routine. 💖

⚠️ note: if a mapping is anywhere non-linear, the vector directional angle may change across the transformation, and an iterative differential technique must be employed to map the second endpoint of the vector. so like, do not freestyle this one.

and when you're creating a new mapping, the user is strongly urged to use the user-modifiable routine VVUMXY, rather than attempting to work with MXF and MYF. consider this your sign from the universe. 🌈

🔑 ACCESS 🔑

to use FX, FY, MXF, and MYF, load the NCAR Graphics libraries ncarg, ncarg_gks, and ncarg_c, preferably in that order. order matters, bestie, it's giving choreography. 💃

👀 SEE ALSO 👀

Online: vectors, streamlines, vectors_params, streamlines_params, vvumxy, stuixy, stumta, stumxy.

go read those too, they're literally right there. 📚

Copyright (C) 1987-2009 University Corporation for Atmospheric Research The use of this Software is governed by a License Agreement.

and that's the whole page, bestie. this one shipped out under UNIX back in April 1993 — ancient artifact, museum piece, we stan a historical document. 💅✨ stay obsolete and stay hydrated 🫶💖

📦 where this page comes from