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

Test various restart formats and add Derecho port that uses pio spack #933

Open
apcraig opened this issue Feb 9, 2024 · 1 comment
Open
Assignees
Labels

Comments

@apcraig
Copy link
Contributor

apcraig commented Feb 9, 2024

As a followup to #928, it might be useful to generate several versions (cdf1, cdf2, cdf5, hdf5) of the CICE test restart file and test the ability of the code to read those formats and be bit-for-bit reproducible between them.

Also, a slightly separate task. It would be good to implement a Derecho port that uses the spack pio install instead of the version build on Derecho. This would probably be a new "machine".

@anton-seaice
Copy link
Contributor

As a followup to #928, it might be useful to generate several versions (cdf1, cdf2, cdf5, hdf5) of the CICE test restart file and test the ability of the code to read those formats and be bit-for-bit reproducible between them.

This could be a good candidate for a unit test, (I haven't looked at all at the current unit tests or how they are set up.). In theory, we can assume the pio + nc interfaces work and are tested, so this can focus more on whether the writing and reading of restart files produces identical results.

Also, a slightly separate task. It would be good to implement a Derecho port that uses the spack pio install instead of the version build on Derecho. This would probably be a new "machine".

Spack and building from source should give identical results. The difference we found is because the build options are different (i.e. whether parallel-netcdf is included.). This gets tricky - because there are hundreds of combinations of build options and library versions etc within the goal of maintaining backward compatibility. One approach might be to try and get a representative sample of the possible variations. Another might be to focus on the up to date / latest stable versions + options and focus on those.

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

No branches or pull requests

2 participants