[MOAB-dev] NAME_TAG_SIZE value?

[Steve Jackson]

On Sep 27, 2010, at 16:23 , Jason Kraftcheck wrote:

> On 09/27/2010 04:20 PM, Jason Kraftcheck wrote:
>> On 09/27/2010 04:09 PM, Tim Tautges wrote:
>>> Ok, go ahead and set it to 64.  But, also run the code through valgrind
>>> to make sure it isn't something else, it can be dangerous doing string
>>> reads/writes (buffer overflows, etc.).
>>> 
>> 
>> This may have some unpleasant side effects.  If the tag is created by a file
>> read, then you'll have a situation where the constant is 64 but the actual
>> tag size is 32.  If the tag is created by MOAB first, then attempts to read
>> files also containing the tag will fail because of the size mismatch.
>> 
> 
> Some solutions:
>  1) Make sure that MOAB always creates the tag and add special cases to
>     all readers to gracefully handle increasing tag size for that tag.
>  2) Also change the tag name so that it is a new tag with the new size.
>     (This is least likely to break applications using the tag values.)
>  3) Fix the cub file reader such that it truncates names that are too
>     long.  (This should be done anyway, even if it isn't an acceptable
>     solution to this problem.)

Sorry to resurrect an old issue, but I just discovered it's causing problems for DagMC users.  Because of the change to NAME_TAG_SIZE, DagMC cannot load an h5m file created before r4170.  

I'm wondering what my options are to fix this.

* DagMC.cpp explicitly creates the name tag (using NAME_TAG_SIZE) before loading a file.  This leads ReadHDF5 to fail, because it determines that the tag data in an old file has a different size than the name tag that was created by DagMC.  Per Jason's solution #1, should DagMC not be creating this tag explicitly?

* Or do we just need to regenerate all our h5m files?  (This would be less painful if mbconvert-ing an old h5m to a new h5m fixed the problem, but that doesn't seem to be the case.)

* Is there some other way to get around this issue?
~S