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
Eventually roms-tools will cover setting up input files, but also analysing them, as well as miscellaneous utilities. I think it would be neater to separate these uses into different namespaces, i.e. roms_tools.setup, roms_tools.analysis, and roms_tools.utils. This would require changing the current top-level imports of Grid etc. to be from roms_tools.setup import Grid etc. instead.
This suggestion assumes that there is no use for the Grid etc. classes in the analysis steps?
The text was updated successfully, but these errors were encountered:
The only class that may be relevant for analysis steps is actually Grid because Grid.ds holds all relevant coordinate information. A lot of this coordinate information is not needed by ROMS itself, but is there for the user so they are able to do analysis, e.g., lat / lon at u- and v-points and vertical coordinate info.
That being said, the content of Grid.ds is written to a NetCDF file, which the analysis classes could read in if they don't want to rely on Grid. But it would be nicer to have them depend on the Grid class I think.
Eventually roms-tools will cover setting up input files, but also analysing them, as well as miscellaneous utilities. I think it would be neater to separate these uses into different namespaces, i.e.
roms_tools.setup
,roms_tools.analysis
, androms_tools.utils
. This would require changing the current top-level imports ofGrid
etc. to befrom roms_tools.setup import Grid
etc. instead.This suggestion assumes that there is no use for the
Grid
etc. classes in the analysis steps?The text was updated successfully, but these errors were encountered: