-
Notifications
You must be signed in to change notification settings - Fork 10
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
Irina/hdf5 c #53
base: master
Are you sure you want to change the base?
Irina/hdf5 c #53
Conversation
re work on connectivity information
… flecsi we start from 0
This compiles OK, needs testing
- Use FleCSI convention of `_u` for incomplete templated things - Need to include MPI to use MPI - Expect Native Int for connectivity data - Example of getting names (unreliable) for error messages - initial tests indicate that Datatypes don't always have retrievable names
…xclusive and shared
Can you please squash this into fewer commits. |
// execute the mpi task to partition the mesh | ||
flecsi_execute_mpi_task(partition_mesh, flecsi_sp::burton, mesh_filename, | ||
max_entries); | ||
if(extension == "exo" || extension == "g") { |
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.
@ipdemes @dmringo I'm looking at extending our runtime selection of type of mesh to parse, in particular looking towards X3D format meshes. Is having separate tasks for each format the approach you two have decided upon? I had stubbed out some code that pushed the if
check down into the task (the singular partition_mesh
task), but this involved casting the mesh definition object (e.g. exodus_definition_t
or x3d_definition_t
) to the common base class mesh_definition_u
for some operations. That was part of the motivation of PR 553 in FleCSI
If we want to go the route of separate tasks for partitioning and initializing, that is fine. It cleans up some things, but does require, perhaps, a bit of code duplication. In general I'm against that sort of thing, but in this particular case I don't really have strong feelings either way.
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.
@cmsquared : do you have your work in a branch somewhere? So I can have a look?
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.
Unfortunately not. But the changes to the partition_mesh
task looked something like this:
// mesh definitions
using mesh_definition_t = flecsi::topology::mesh_definition_u<num_dims>;
using exodus_definition_t = flecsi_sp::io::exodus_definition__<num_dims, real_t>;
using x3d_definition_t = flecsi_sp::io::x3d_definition__<num_dims, real_t>;
// load the mesh
auto filename_string = filename.str();
std::unique_ptr<mesh_definition_t> mesh_def;
if (filename_string.find(".exo") != std::string::npos)
mesh_def = std::make_unique<exodus_definition_t>(filename_string);
else if (filename_string.find(".x3d") != std::string::npos)
mesh_def = std::make_unique<x3d_definition_t>(filename_string);
else
clog_fatal("Burton specialization doesn't know how to read " <<
filename_string);
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.
@cmsquared I'm looking at this again, and liked your approach, but ran into problems resolving the write
method on the mesh definition (called near the end of partition_mesh
) since it's not part of the abstract mesh_definition_u
interface. Did you cast to the concrete implementation to solve this? Unless there are plans to add that method to the interface in FleCSI, that makes it seem like a partition_mesh
task templated on the IO backend would be preferred.
Creating a new pull request for the work @dmringo was doing