Skip to content

read EAM native spectral-element grids, and make formats pluggable - #141

Open
berkgeveci wants to merge 1 commit into
Kitware:masterfrom
berkgeveci:feat/dycore-reader
Open

berkgeveci wants to merge 1 commit into
Kitware:masterfrom
berkgeveci:feat/dycore-reader

Conversation

@berkgeveci

Copy link
Copy Markdown
Collaborator

QuickView handled one grid: the ne*pg2 physics grid, whose SCRIP connectivity gives every cell its own four corners and whose values are cell averages. The dynamical core runs on GLL nodes shared between spectral elements, and its values are nodal point samples -- the opposite shape. Supporting both means the format, not the application, has to decide what the pipeline looks like.

pipeline.py now has a DataPath base with one subclass per format, chosen by sniffing the connectivity file (element_corners vs corner_lat):

Pg2Path cell data reader > CenterMeridian > Extract > Project > Surface
DycorePath point data reader > CenterMeridian > Extract > Project > Surface

EAMDycoreSource is the tier-1 reader: one bilinear quad per (np-1)^2 subcell, vertices are the GLL nodes, so no topology is reconstructed and no point is invented. It lays the sphere flat itself, duplicating nodes at the date line and the poles rather than clipping, which keeps every cell whole and every value exact. HOMME winds element_corners inward, so the winding is reversed at read time; a pole node's longitude is arbitrary and must take no part in the seam test, or float noise flings a corner a whole turn out of the map.

The map's longitude window is now movable: the left edge sits anywhere in [-180, 180] and the right edge a turn east of it. One rule shared by every filter -- cut at c = input_origin + (origin - input_origin) % 360, translate the halves by origin+360-c and origin-c -- and at origin -180 with a [0, 360) input it reduces to the previous hardcoded behaviour. EAMCenterMeridian needs to be told its input's window because the two readers emit different ones. The projection is re-centred before PROJ sees it: PROJ normalises longitude into [-180, 180) before applying lon_0, which would send the window's right edge to the left rim and draw cells and coastlines across the map.

Association is plumbed through view_panel, compute.extract_avgs and app.py, and ViewManager.drop_views() discards views on a format switch, since each binds its mapper to the tail of one specific pipeline.

Performance: EAMCenterMeridian passes through untouched when the input already sits in the requested window (the dycore default), and on a real rebuild hands the cached points and cells objects downstream, because EAMProject keys its cache on point identity and EAMExtract on their modified time. EAMExtract keeps its cache for nodal data through a point pedigree map -- it removes whole cells and never interpolates, so the ids stay exact. Roughly 7 ms per pipeline pass at ne30 with 20 variables loaded, matching pg2.

Verified against ParaView 6.0.1 (VTK 9.5.2) and ParaView master (VTK 9.7).

…s pluggable

QuickView handled one grid: the ne*pg2 physics grid, whose SCRIP connectivity
gives every cell its own four corners and whose values are cell averages. The
dynamical core runs on GLL nodes shared between spectral elements, and its
values are nodal point samples -- the opposite shape. Supporting both means the
format, not the application, has to decide what the pipeline looks like.

pipeline.py now has a DataPath base with one subclass per format, chosen by
sniffing the connectivity file (element_corners vs corner_lat):

  Pg2Path     cell data    reader > CenterMeridian > Extract > Project > Surface
  DycorePath  point data   reader > CenterMeridian > Extract > Project > Surface

EAMDycoreSource is the tier-1 reader: one bilinear quad per (np-1)^2 subcell,
vertices *are* the GLL nodes, so no topology is reconstructed and no point is
invented. It lays the sphere flat itself, duplicating nodes at the date line
and the poles rather than clipping, which keeps every cell whole and every
value exact. HOMME winds element_corners inward, so the winding is reversed at
read time; a pole node's longitude is arbitrary and must take no part in the
seam test, or float noise flings a corner a whole turn out of the map.

The map's longitude window is now movable: the left edge sits anywhere in
[-180, 180] and the right edge a turn east of it. One rule shared by every
filter -- cut at c = input_origin + (origin - input_origin) % 360, translate
the halves by origin+360-c and origin-c -- and at origin -180 with a [0, 360)
input it reduces to the previous hardcoded behaviour. EAMCenterMeridian needs
to be told its *input's* window because the two readers emit different ones.
The projection is re-centred before PROJ sees it: PROJ normalises longitude
into [-180, 180) before applying lon_0, which would send the window's right
edge to the left rim and draw cells and coastlines across the map.

Association is plumbed through view_panel, compute.extract_avgs and app.py,
and ViewManager.drop_views() discards views on a format switch, since each
binds its mapper to the tail of one specific pipeline.

Performance: EAMCenterMeridian passes through untouched when the input already
sits in the requested window (the dycore default), and on a real rebuild hands
the cached points and cells objects downstream, because EAMProject keys its
cache on point identity and EAMExtract on their modified time. EAMExtract keeps
its cache for nodal data through a point pedigree map -- it removes whole cells
and never interpolates, so the ids stay exact. Roughly 7 ms per pipeline pass
at ne30 with 20 variables loaded, matching pg2.

Verified against ParaView 6.0.1 (VTK 9.5.2) and ParaView master (VTK 9.7).
@berkgeveci

Copy link
Copy Markdown
Collaborator Author

@jourdain can you review?

@berkgeveci
berkgeveci requested a review from jourdain September 18, 2026 16:56
for view in list(self._var2view.values()):
view.colormap.update_color_range() # colormaps module

def drop_views(self):

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't see where that is getting called, but having it seems good for a follow up integration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants