libMesh
Enable block restricted Exodus output
In our MOOSE-based application, we automatically construct a mesh that includes blocks used exclusively for transferring data from the main app to the sub-app. It would be very beneficial to have the option to hide these blocks from the Exodus output as the user need not know about them.
@GiudGiud mentioned that this should not be very difficult to implement and that it would have to be enabled inside libmesh, hence this issue.
This doesn't sound like it would be particularly easy to me, because the Exodus file format is tied very tightly to the "block" ordering (aka subdomain)-based, but I could be wrong. Also, I think you might run into unexpected "renumbering" of Elems and or Nodes in the output. If the goal is simply to hide the blocks from the user it might be best to handle that during visualization (assuming that is where the user usually sees them) by turning off the blocks in Paraview?
Interesting, I'll let @GiudGiud describe what he had in mind, but I remember using seacas a while back to create a subset of an Exodus file (although it had the annoying side effect of making all the variable names upper case) which is why I assumed performing this kind of operations was straightforward.
As far as turning them off during visualization, it is currently what users have to do. It may not sound like a big deal but there can be hundreds if not thousands of them (again, these blocks are only used to transfer data and having that many blocks does not seem to be an issue) and the same number of blocks to be visualized - so doing it manually is very tedious.
@vincentlaboure do you have any nodal variables? For nodal variables it does look a little tricky to add this. But for element variable there is already all the code in there to work with their block restriction, dealing with the mesh block restriction is likely reasonable.
@GiudGiud For the 2 applications that we have in mind, the mesh consists of two groups of subdomains S1 and S2 such that S1 and S2 do not share any node. The hope is that we can block restrict the Exodus output to S1. There are nodal variables defined on S1 (for the first application, the nodal variables are only defined on S1; for the other the nodal variables are defined on both S1 and S2).
Does that simplify the request?
Does that simplify the request?
Unfortunately not, the code for nodal variables is as @jwpeterson making large use of the match between solution vector and mesh ordering.
We could get constant monomial variables done as a first cut and reconsider after
