-
Notifications
You must be signed in to change notification settings - Fork 90
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
Conversation
`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)
The boutconf branch might help with that, as that lets you query how bout was configured.
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?
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 ... |
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 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. |
975343b
to
9023cfd
Compare
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
} else { | ||
f.setIndex(f.getMesh()->YLOCAL(0)); | ||
f.setIndex(f.getMesh()->getLocalYIndexNoBoundaries(0)); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
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.
I think this needs #2095 for the tests to pass. BTW, I tested with the netcdf-legacy and the tests pass, but |
There was a problem hiding this 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.
I guess we should drop legacy netcdf and hdf5 with the 5.0 release. |
It looks like this should just go into #2095 ?
After we get 4.3.2 and 4.4.0 out, I want to look at completely replacing datafile with |
That sounds sensible. |
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
Fixes #2003
Also:
DataFormat::writeFieldAttributes
withFieldPerp
: need to use the global index that doesn't include boundariestest-io_hdf5
needing globalmesh/dump
getGlobal
versions, replacing{X,Y}LOCAL
, and are necessary for consistent, unique global indices into the boundaries for double-null tokamak gridsThere 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 inruntest
. 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.