[MOAB-dev] NAME_TAG_SIZE value?

[Rajeev Jain]

Well, for the purposes of converting a big mesh file from one format to the 
other, I was using a NAME_TAG_SIZE larger than 32.
At one point I had to change this (locally) size to a size much larger than 64. 

I think, I should handle this change locally and revert the change below, to 
keep things in-order.

--- MOAB/trunk/src/MBTagConventions.hpp    2010-09-27 21:12:38 UTC (rev 4169)
+++ MOAB/trunk/src/MBTagConventions.hpp    2010-09-27 21:17:16 UTC (rev 4170)
@@ -100,6 +100,6 @@
  * storing or searching for a value must be padded with '\0' chars.
  */
#define NAME_TAG_NAME "NAME"
-#define NAME_TAG_SIZE 32
+#define NAME_TAG_SIZE 64 Rajeev





________________________________
From: Steve Jackson <sjackson at cae.wisc.edu>
To: Jason Kraftcheck <kraftche at cae.wisc.edu>
Cc: moab-dev at mcs.anl.gov
Sent: Thursday, November 11, 2010 15:21:43
Subject: Re: [MOAB-dev] NAME_TAG_SIZE value?


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20101111/9b1c5f9d/attachment.htm>