Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: rework some of the dart netcdf utilities mod #654

Open
nancycollins opened this issue Mar 12, 2024 · 3 comments
Open

Feature request: rework some of the dart netcdf utilities mod #654

nancycollins opened this issue Mar 12, 2024 · 3 comments
Labels
back burner very low priority. Future work?

Comments

@nancycollins
Copy link
Collaborator

Use case

Low priority:

The DART netcdf utilities cover functions are intended to avoid calling netcdf functions directly and using more descriptive names. Users who aren't familiar with programming the netcdf API face a steep learning curve. Lots of users are familiar with ncdump and netcdf utilities, but not creating and accessing netcdf files at the programming level. It's a low level interface and the resulting code is hard to read even if you know netcdf. We have lots of netcdf code in dart which could be much easier for users to read if it used these functions.

However, they were never intended to replace all calls to netcdf. They are intended to have user code avoid having to 'use' the netcdf module directly. This isolates the netcdf calls to a fewer number of modules. If we ever wanted to support a different file format natively in dart, this would ease the development burden.

Is your feature request related to a problem?

i see that 3 netcdf constants have been added to the dart netcdf module. they should either be inside cover functions that are named to better describe their use, or they should have different names to avoid them looking exactly like the netcdf constants. e.g. if you need to declare an array with a fixed size, you might need a parameter value. but should be a dart constant, not a netcdf NF90 constant.

also, the function nc_get_variable_info() should be removed. it passes netcdf-specific constants back to the calling code. the caller should either use netcdf directly, or substitute functions should be used. it is also a completely different style. all the other functions do a single thing with simple args. this one has a long arg list, which are all optional, so exactly what is being queried is unclear in the calling code unless the user carefully names their variables. it's a valid style, just incompatible with the rest of the style of this module.

Describe your preferred solution

This is a low-priority issue. I only opened this issue because once someone starts doing something quick and dirty it snowballs into unmaintainable code eventually. Someday when someone wants to clean up this should be addressed, maybe in the context of some other i/o work.

@hkershaw-brown
Copy link
Member

this is where the first two came in:
#102 (comment)

@hkershaw-brown hkershaw-brown added the back burner very low priority. Future work? label Mar 14, 2024
@hkershaw-brown
Copy link
Member

I do want to step back before making any 'should' and 'shouldn't' decisions on this.
I think there is some ambiguity in the intent and the use of netcdf_utitilites_mod.
Whether it is a wrapper for netcdf, an ease of programming tool to certain common tasks when working with netcdf files, or if it is part of the path to using something other than netcdf for fileformat.

@nancycollins
Copy link
Collaborator Author

this is an interesting observation. the original intent of the module was to simplify the code end users saw in their model_mods. it wasn't trying to replace all netcdf calls inside dart. then it morphed into trying to reduce the number of other dart modules that had a 'use netcdf' in them, with the thought that longer term maybe this layer could help intercept i/o requests and plug in more than just netcdf underneath. but it wasn't originally designed that way so i'm afraid a lot of the subroutines, while simplified, are still heavily netcdf-flavored. trying to design a more general file i/o interface layer is an idea to explore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
back burner very low priority. Future work?
Projects
None yet
Development

No branches or pull requests

2 participants