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

Fix some HDF5 related issues and add Mesh::getLocal{X,Y,Z}Index #2102

Merged
merged 19 commits into from
Sep 25, 2020

Conversation

ZedThree
Copy link
Member

@ZedThree ZedThree commented Sep 21, 2020

Fixes #2003

Also:

  • Fix bug in DataFormat::writeFieldAttributes with FieldPerp: need to use the global index that doesn't include boundaries
  • Fix test-io_hdf5 needing global mesh/dump
  • Build with HDF5 on Travis
  • Require netCDF for some tests that use grid files
  • Add Mesh::getLocal{X,Y,Z}Index{NoBoundaries} methods: these are inverses of the getGlobal versions, replacing {X,Y}LOCAL, and are necessary for consistent, unique global indices into the boundaries for double-null tokamak grids

There are some tests that can't use HDF5 because they use grid files, and I don't think we want to have duplicate binaries just in different formats. There are some other tests that could use HDF5 but currently can't because we'd need to be able to change the file extension in the runtest script. And some others which should be run with both HDF5 and netCDF, including some duplicated ones that could be merged, if we could query what formats are available in runtest. Not sure how much I actually want to do there, I'm not terribly certain we want to support HDF5 into the future.

Fedora test is failing because it needs h5py, but I didn't know where to specify that -- @dschwoerer does it need to be in your BOUT++ Fedora recipe? If so, is it possible to give me maintainer access to that?

Some of this should be backported.

`H5Awrite` and `H5Aread` actually need `(const) char**`: I ended up
just looking at the source for the C++ API to see how they do it
themselves
Writing `yindex_global` was not the inverse of reading it
- Apply black formatting
- Suppress warning from `rm`
- Don't quit on first failure
- Fix typo ("Field3D" -> "Field2D")
- Use `numpy.allclose`
Some tests use grid files which puts a hard dependency on netCDF, but
others could be adapted to use either netCDF or HDF5 if we had a nice
way to determine which is available at test-time (and maybe run the
test for both if needed)
@ZedThree ZedThree added bugfix backport candidiate Does not break backward compatibility, so can be back-ported to v4.4 labels Sep 21, 2020
src/fileio/dataformat.cxx Outdated Show resolved Hide resolved
@dschwoerer
Copy link
Contributor

And some others which should be run with both HDF5 and netCDF, including some duplicated ones that could be merged, if we could query what formats are available in runtest.

The boutconf branch might help with that, as that lets you query how bout was configured.

Not sure how much I actually want to do there, I'm not terribly certain we want to support HDF5 into the future.

I'd be in favor to only support one backend - makes it easier to maintain and test. Or what is the advantage of HDF5? Slighly easier to install compared to netcdf?

Fedora test is failing because it needs h5py, but I didn't know where to specify that -- @dschwoerer does it need to be in your BOUT++ Fedora recipe? If so, is it possible to give me maintainer access to that?

I added it to the install line. I wouldn't mind giving you access to the package in fedora, but that requires you to be a packager, which involves demonstrating you know the packaging rules of fedora. I certainly learned a lot in the process and it is fun, but also requires a bit of time ...

@johnomotani
Copy link
Contributor

I don't really remember (maybe @bendudson does?), but I think there was a thought at one point that some project (maybe the American SciDAC?) would standardise on HDF5, and it would be useful to be able to integrate with that. I happened to be working on an HDF5 interface for another project a few years ago, so thought I might as well put in a BOUT++ one while I was looking up the function calls.

I'd support standardising to one backend. netCDF seems better in my opinion, the ecosystem of tools around xarray, etc. all seems to be built mostly on netCDF. There shouldn't be any performance difference because netCDF is just HDF5 with extra conventions for metadata.

I would like to get rid of the netcdf-cxx4 dependency though if we're refactoring the backends. It always seems to be a bit of a pain to get onto clusters, and in my experience isn't provided in the modules.

These are inverses of the `getGlobal` versions, replacing
`{X,Y}LOCAL`, and are necessary for consistent, unique global indices
into the boundaries for double-null tokamak grids
@ZedThree ZedThree changed the title Fix some HDF5 related issues Fix some HDF5 related issues and add Mesh::getLocal{X,Y,Z}Index Sep 22, 2020
include/bout/mesh.hxx Outdated Show resolved Hide resolved
src/fileio/dataformat.cxx Outdated Show resolved Hide resolved
src/fileio/dataformat.cxx Outdated Show resolved Hide resolved
} else {
f.setIndex(f.getMesh()->YLOCAL(0));
f.setIndex(f.getMesh()->getLocalYIndexNoBoundaries(0));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes sense to keep getLocalYIndexNoBoundaries(0) here, as that sets a default value on a grid cell rather than (possibly) in a boundary cell.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this, might be better to just fail?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to not fail so we can successfully read old restart files, which might (I think? haven't checked the actual history...) exist with FieldPerps but without yindex_global attributes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds reasonable, I'm just not sure how you'd deal with such a field? You'd need to set the index via some other means

src/mesh/impls/bout/boutmesh.cxx Outdated Show resolved Hide resolved
include/bout/mesh.hxx Outdated Show resolved Hide resolved
include/bout/mesh.hxx Outdated Show resolved Hide resolved
include/bout/mesh.hxx Outdated Show resolved Hide resolved
include/bout/mesh.hxx Outdated Show resolved Hide resolved
include/bout/mesh.hxx Outdated Show resolved Hide resolved
ZedThree and others added 2 commits September 23, 2020 16:23
Co-authored-by: johnomotani <john.omotani@ukaea.uk>
Use boundary-aware form of global index conversion, but check it's an
interior point when writing it.
@ZedThree ZedThree mentioned this pull request Sep 23, 2020
@johnomotani
Copy link
Contributor

I think this needs #2095 for the tests to pass.

BTW, I tested with the netcdf-legacy and the tests pass, but fperp2 is not read or written on the correct processors! The legacy netcdf interface just fails to read attributes from the benchmark file. Maybe because it's a NetCDF4-format and legacy netcdf doesn't support NetCDF4 properly? I changed the runtest scripts in #2095, so I'll add a check of the attributes in that PR.

johnomotani
johnomotani previously approved these changes Sep 23, 2020
Copy link
Contributor

@johnomotani johnomotani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than a merge of #2095, this looks good to me.

@dschwoerer
Copy link
Contributor

I guess we should drop legacy netcdf and hdf5 with the 5.0 release.
I think it is better to fail early and with a clear error, then to try to do the wrong thing, but produce slightly wrong results.

@ZedThree
Copy link
Member Author

It looks like this should just go into #2095 ?

I guess we should drop legacy netcdf and hdf5 with the 5.0 release.

After we get 4.3.2 and 4.4.0 out, I want to look at completely replacing datafile with OptionsNetCDF

@johnomotani
Copy link
Contributor

It looks like this should just go into #2095 ?

That sounds sensible.

src/fileio/dataformat.cxx Outdated Show resolved Hide resolved
To be more precise, mark the global yindex for FieldPerps in guard
cells as invalid when writing them, and set the (local) yindex to be
invalid if its in a guard cell on this processor when reading them.

It is still possible to write FieldPerps in guard cells, it's just
that `collect` won't read them, and the user will need to use a
lower-level API to do so.
Also:
- Don't plot anything on failure by default
- Clean up quietly
- More consistent pass/fail message
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport candidiate Does not break backward compatibility, so can be back-ported to v4.4 bugfix
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants