Expand Exodus name limits #4229
Conversation
We have users running up against the 32-character limit, and it looks like we ought to be able to go to 80.
We're no longer truncating these on write or read.
jwpeterson
left a comment
jwpeterson
left a comment
There was a problem hiding this comment.
Interesting that all those exo files got bigger even though their contents should not have changed, I guess it's because we are writing more "blank" padding spaces at the end of every string whether we need them or not?
|
I think we are writing more blank padding spaces, but I also added some long subdomain names to the tests that use those files (which was a good idea; just tossing a few exII calls in blind turned out to require a couple bug fixes afterward), so the files should have all changed regardless. |
|
The MOOSE test failures I should have anticipated; those are truncated gold files upstream. The DistributedMesh failures look like a simple mistake to fix. |
Usually we do this as we read a file or keep things in sync as we generate a mesh, but there may be cases where we can't do either easily.
Add error handling, and avoid Exodus warnings from invalid calls in parallel.
It'll be less of a pain for users exodiffing against old truncated exodus files if they have manual control over truncation.
I've verified that without this the tests fail, as they should.
|
Rather than either (A) fiddling with a ton of MOOSE exodiffs before we can get this in or (B) saying I'll fiddle with a ton of MOOSE exodiffs and never getting around to it (this was an August PR???) or (C) trying to sync up the libMesh changes with a MOOSE submodule update and fiddling ... I'm just making it user-controllable. We'll default to 32-char truncation, then we can bump it up to 80 downstream and either add an option in MOOSE or fiddle with exodiff gold files at the same time (probably the former, because I'll bet a bunch of MOOSE apps have the same problem), then we can make the libMesh default sane afterward without breaking a ton of exodiffs or having to stay perfectly in sync with downstream. |
jwpeterson
left a comment
jwpeterson
left a comment
There was a problem hiding this comment.
Looks good to me (imagine the dial goes up to 80).
|
I'm fine with this being user-controllable, but how do I control it? I have a MOOSE App for my use case that needs longer block names, which has its own libmesh installation. Would the name length limit be set when configuring libmesh? Or can my App control it? Is it set a compile-time or run-time? |
|
Going from 32 to 80 is a run-time setting; once this gets into MOOSE I'll add it to the Exodus options there. Going from 80 to 81 appears to be a "edit an Exodus header and recompile Exodus" thing; if you need that much length you might still be stuck with your own libMesh builds. |
|
Personally, I'm not happy with this being user-controllable; that's just a way to ease the transition for users who've golded files with truncated names. Long-term the plan is "it defaults to 80 and nobody should care about the option to change that unless they really need to match names in a file they can't regold", hopefully before too much longer. |
|
80 is plenty! |
4 participants
We have users running up against the 32-character limit, and it looks like we ought to be able to go to 80.