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

Backward compatibility for parallel netcdf opens #103

Closed
anton-seaice opened this issue Feb 16, 2024 · 7 comments
Closed

Backward compatibility for parallel netcdf opens #103

anton-seaice opened this issue Feb 16, 2024 · 7 comments
Assignees
Labels
bug Something isn't working

Comments

@anton-seaice
Copy link
Contributor

There is a corner-case bug in our build of ParallelIO 2.5.10 when built without Pnetcdf (per the cosima-spack)

If you attempt to open a netcdf3 file, with the file type flags set for netcdf4 (e.g. pio_typename = netcdf4p in nuopc.runconfig), PIO should fallback to doing a non-parallel open and open the file, however it fails with the error 'Abort with message NetCDF: Attempt to use feature that was not turned on when netCDF was built.' This was fixed in PIO 2.6.2.

There is a work around, which is to use nccopy to generate a netcdf4 file from the netcdf3 file. Otherwise the fix is to update to PIO 2.6.2 (which requires an update to the spack package, with version("2.6.2", sha256="c318894f0230197458917e932ec66301b4407a744df481e9c6a6d9d85f7e5ab1") - its in the main version now , although pins us to netcdf 4.9.2 - which is the same as our current version )

It is probably unlikely this is an issue for us. It would only come up if we wanted to use old restart / initial conditions / grid files (probably not supported?) or we wanted to switch between netcdf3 & netcdf4 part way through an experiment.

@anton-seaice anton-seaice added the bug Something isn't working label Feb 16, 2024
@micaeljtoliveira
Copy link
Contributor

@anton-seaice I can update the PIO version used in our spack instance. That should be quite simple to do.

@anton-seaice
Copy link
Contributor Author

Do we need to keep our own version of the PIO package? Maybe we can use the main spack package?

diff -ru repos/cosima/packages/parallelio/ spack/var/spack/repos/builtin/packages/parallelio/
diff -ru repos/cosima/packages/parallelio/package.py spack/var/spack/repos/builtin/packages/parallelio/package.py
--- repos/cosima/packages/parallelio/package.py 2024-02-16 15:40:25.000000000 +1100
+++ spack/var/spack/repos/builtin/packages/parallelio/package.py        2024-02-16 15:13:21.000000000 +1100
@@ -50,8 +50,6 @@
     # Allow argument mismatch in gfortran versions > 10 for mpi library compatibility
     patch("gfortran.patch", when="@:2.5.8 +fortran %gcc@10:")
-    flag_handler = CMakePackage.build_system_flags
-
     def cmake_args(self):
         define = self.define
         define_from_variant = self.define_from_variant
Binary files repos/cosima/packages/parallelio/__pycache__/package.cpython-311.pyc and spack/var/spack/repos/builtin/packages/parallelio/__pycache__/package.cpython-311.pyc differ

@micaeljtoliveira
Copy link
Contributor

micaeljtoliveira commented Feb 18, 2024

Ah, I need to submit that fix upstream. Yes, we need to keep it for now, as otherwise we can't set our own compiler flags correctly.

@anton-seaice
Copy link
Contributor Author

Cool thanks :) (FYI @harshula )

@micaeljtoliveira
Copy link
Contributor

@anton-seaice Latest spack environment uses PIO 2.6.2. Shall we close this issue?

@anton-seaice
Copy link
Contributor Author

I will test first :)

@anton-seaice anton-seaice self-assigned this Apr 5, 2024
@anton-seaice
Copy link
Contributor Author

I made a netcdf 3 copy of grid.nc, and cice loaded that successfully using the new spack - 0.21.2 build

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants