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: Automate the initial creation of new observation converters #684

Open
hkershaw-brown opened this issue May 29, 2024 · 0 comments
Assignees

Comments

@hkershaw-brown
Copy link
Member

Use case

A user wants to add a new observation converter, where do they start from?

Is your feature request related to a problem?

When a user wants to add a new observation converter (obs_converters) to DART they typically copy an existing obs_converter directory. This has a few unwanted side effects:

  • Copied code from an existing observation converter is not necessary relevant to the new observation converter (code is messier than it needs to be)
  • Users are not necessarily getting the latest code/best practices (creates more work for DART developers during pull requests)
  • Copied documentation can be misleading (it looks up to date, but it is for another observation converter)

Describe your preferred solution

Create a script that automatically sets up an observation converter for users to start developing and writing their documentation. I believe with good template files for X_to_obs.f90 we can have a observation converter that compiles from the get-go ( note: this may not be true).

We have a new_model automation, implemented by Benjamin Gunn #376 #349. This is a good reference.

e.g. for a new converter for the PACE satellite
which uses the threed_sphere location mod and the PACE data is in netcdf:

./new_converter PACE threed_sphere netcdf

Would give you the starting point:

DART/observations/obs_converters/PACE/
                                     pace_to_obs.f90
                                     pace_to_obs.rst
                                     work/
                                          quickdbuild.sh
                                          input.nml

Describe any alternatives you have considered

I think we just need code that writes code.
There is probably a lot of boiler plate code (e.g. read lat, lon, variable from netcdf) that could be tidied/automated or at least given sensible defaults.

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

No branches or pull requests

2 participants