You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, all core routines are modeled very closely after the corresponding PyOM routines, including variable names and code structure. Additionally, all gradients are calculated via index shifting and slicing. This makes the code hard to read and understand, but has a performance impact, too, since temporary arrays cannot be freed until the (often overly long) routine has finished.
From the top of my head, possible enhancements include:
An xarray-style shifting / gradient function instead of explicit index shifts
Re-working of some particularly problematic variables like flux_east / flux_north / ...
Giving meaningful names to all variables (especially everything currently named fxa, temp, ...)
More (inline?) functions instead of docstring-separated code blocks
The text was updated successfully, but these errors were encountered:
Currently, all core routines are modeled very closely after the corresponding PyOM routines, including variable names and code structure. Additionally, all gradients are calculated via index shifting and slicing. This makes the code hard to read and understand, but has a performance impact, too, since temporary arrays cannot be freed until the (often overly long) routine has finished.
From the top of my head, possible enhancements include:
xarray
-style shifting / gradient function instead of explicit index shiftsflux_east
/flux_north
/ ...fxa
,temp
, ...)The text was updated successfully, but these errors were encountered: