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.

Sign up for GitHub

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

Jump to bottom

Changes to XDMFEntry to use uint64_t data types #13626

Merged
merged 1 commit into from Apr 25, 2022
Merged

Changes to XDMFEntry to use uint64_t data types #13626

merged 1 commit into from Apr 25, 2022

Conversation

singimarson
Copy link
Contributor

No description provided.

tjhei
tjhei reviewed Apr 20, 2022
View reviewed changes
Copy link
Member

@tjhei tjhei left a comment

Choose a reason for hiding this comment

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

I think this is good. One might argue to use a different data type and only a 64 bit type if deal.II is compiled with 64 bit and indices, but I think the current approach is easier and handles the case that a large subdivision number pushes the number of nodes above 32bits.

source/base/data_out_base.cc
@@ -7895,7 +7895,7 @@ DataOutInterface<dim, spacedim>::create_xdmf_entry(
const double cur_time,
const MPI_Comm & comm) const
{
unsigned int local_node_cell_count[2], global_node_cell_count[2];
std::uint64_t local_node_cell_count[2], global_node_cell_count[2];
Copy link
Member

Choose a reason for hiding this comment

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

You also have to fix the data type of the MPI call a couple of lines down from here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you, good catch. Should be fixed now!

XDMFEntry commit
1e9da7b 
Changed the constructors of XDMFEntry to allow for uint64_t datatypes
that we need for large data.  Changed some things in create_xdmf_entry
to match.
@tjhei
Copy link
Member

tjhei commented Apr 20, 2022

Do the xdmf files still generate correctly? Can you still open in paraview?

@singimarson
Copy link
Contributor Author

singimarson commented Apr 20, 2022 •
edited

@tjhei Yes, I just tested it now and I can run my xdmf modified version of step-40 on my machine.

@tjhei
Copy link
Member

tjhei commented Apr 20, 2022

/rebuild

@tjhei
Copy link
Member

tjhei commented Apr 22, 2022

I was trying to run the hdf5 tests on my machine, but they fail on master for me as well:

$ ctest -R hdf5
76% tests passed, 8 tests failed out of 34

The following tests FAILED:
        1566 - base/hdf5_03.mpirun=1.debug (Failed)
        1567 - base/hdf5_03.mpirun=1.release (Failed)
        1568 - base/hdf5_03.mpirun=4.debug (Failed)
        1569 - base/hdf5_03.mpirun=4.release (Failed)
        1572 - base/hdf5_05.mpirun=1.debug (Failed)
        1573 - base/hdf5_05.mpirun=1.release (Failed)
        1574 - base/hdf5_05.mpirun=4.debug (Failed)
        1575 - base/hdf5_05.mpirun=4.release (Failed)

I will investigate.

@peterrum peterrum added this to the Release 9.4 milestone Apr 24, 2022
@tjhei
Copy link
Member

tjhei commented Apr 24, 2022

Well, XDMF has nothing to do with the base/hdf5* tests (they test the c++ HDF5 API and not the graphical output). So I think this is safe to merge. I am keeping track of the failing tests at #13638

@peterrum peterrum merged commit 0a36820 into dealii:master Apr 25, 2022
@tjhei tjhei mentioned this pull request May 10, 2022
Closed
@singimarson singimarson deleted the xdmf branch February 9, 2023 13:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@tjhei tjhei tjhei left review comments

@peterrum peterrum peterrum approved these changes

Assignees
No one assigned
Labels
ready to test
Projects
None yet
Milestone
Release 9.4
Development

Successfully merging this pull request may close these issues.

None yet
3 participants
@singimarson @tjhei @peterrum