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

Field serialisation utilities #72

Open
awnawab opened this issue Jan 16, 2025 · 4 comments
Open

Field serialisation utilities #72

awnawab opened this issue Jan 16, 2025 · 4 comments
Labels
enhancement New feature or request

Comments

@awnawab
Copy link
Collaborator

awnawab commented Jan 16, 2025

To enable testing of standalone components, and to aid debugging, we wish to add basic I/O functionality that allows fields to be easily saved to and loaded from file. Importantly, this functionality is not intended to replace the model I/O, but rather simply to enable model/state serialisation. In terms of the I/O format to be used, my first instinct is to just use HDF5.

@awnawab awnawab added the enhancement New feature or request label Jan 16, 2025
@awnawab
Copy link
Collaborator Author

awnawab commented Jan 16, 2025

@dareg, @pmarguinaud I would really appreciate your input on this, especially on the choice of I/O format. Many thanks! 🙏

@dareg
Copy link
Collaborator

dareg commented Jan 17, 2025

Hello,

Maybe it should belongs to a completely separate "project" or repository inside the ecmwf-ifs github organisation, since it's not a core functionality of field_api. I think it would be better to not grow field_api too much and to try to keep it on point as much as possible.

So we could have repositories like field_api_serialisation_hdf5 or also field_api_serialisation_netcdf if we want to experiment with other formats (but I think HDF5 is a good choice, it's common, works fine, and there's usually tools at hand to read it).

@dareg
Copy link
Collaborator

dareg commented Jan 17, 2025

On the other hand, I guess it would be fine if the implementation was self-contained, like in a single file or a set of files and let it be completely optional (so we would still be able to compile field_api without any installation of HDF5).

@awnawab
Copy link
Collaborator Author

awnawab commented Jan 17, 2025

Yes I agree, the I/O utils should be both cleanly separated and optional (off by default). Thanks for the feedback! 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants