April 2010 - moab-dev - mailman3.cels.anl.gov

Reader/Writer filename extension access
by Robert Smith 30 Apr '10

30 Apr '10

I'm looking for some comments on Ticket #142 and my thoughts below. Ticket #142 asks for 3 things from the Reader/Writer interface: 1) Given an extension or filename, get the name or actual reader/writer that can handle it 2a) Get the extensions a reader/writer handles and 2b) possibly all the readers/writers registered. I believe 1) is covered by the existing interface on ReaderWriterSet. The get_file_extension_reader/ get_file_extension_writer functions do this. For 2b) this could be done fairly easily. Just return a vector of ReaderIface* or WriterIface*. I'm not sure what this would be used for but it could be done. It is 2a) that is more tricky. Currently the extensions are registered with a Reader and/or Writer factory method directly in the ReaderWriterSet constructor. This is the only place the extensions are known. What 2a) is asking is to go from an object instance of a subclass of ReaderIface or WriterIface and retrieve these associated extensions. I see 2 possibilities: A - have a function that searches through the ReaderWriterSet list of registered factory methods and matches the factory method on a particular subclass of ReaderIface/WriterIface. B - move the extensions to the actual Reader/Writer classes as a static data member that could be returned by either a static member function (for use in registration in ReaderWriterSet) or a virtual function defined on ReaderIface (for use to solve 2a) above). I'm not sure 'A' really works but it seems as though it should. ReaderIface/WriterIface would have new virtual functions to request the information. These would be implemented in the Reader/Writer classes as requests to the ReaderWriterSet passing in the function pointer of their own static factory function. For 'B' the technical aspects of the implementation are straightforward. The complication comes from the fact that you can register a Reader, a Writer or both for a set of extensions. To do 'B' simply we could put the static extension data into both a Reader and Writer class if both existed. And then in ReaderWriterSet just choose which one you would use in the registration. This is not ideal as we have duplicated data. A possible solution would be to add in IoXxx classes (I'm open to better names). For example, create an IoGmsh class. It would have the extensions as static data and methods to access them. This IoGmsh class could also contain the format name string and description strings also. ReaderGmsh/WriterGmsh would then inherit from this IoGmsh class in addition to ReaderIface. See attached file for example code. This implementation could also handle the instances of multiple extension sets and format names as is the case for ReadCGM by making the extensions an array of arrays of char* and the format an array of char*. My preferred approach would be 'A' as it involves little disruption to the current design. But I'm not sure it will work. Option 'B' involves more changes and multiple inheritance. I'm also wondering at the utility of this functionality in the first place. When would someone have a ReaderIface* to a Reader/Writer object and want to know the extensions it supports? Any thoughts would be appreciated. --Bob

6 23

Floating point exceptions in MOAB
by Steve Jackson 28 Apr '10

28 Apr '10

MOAB divides by zero sometimes. I discovered this because a CGM dependency enabled floating point exceptions without my knowledge, and that caused my program to abort when a zero division occurred inside MOAB. The particular zero division I ran into occurs in GeomUtil.cpp, in the function segment_box_intersect(). (Only the KD tree code calls this function.) This zero division is not a bug: the result is checked using finite(), and discarded if infinite. Grepping the code for other occurrences of finite() suggests that this idiom exists in a handful of other places in MOAB. (Most of these places are geometry-related: KD trees, BSP trees, oriented boxes.) Code like this isn't inherently buggy, but it does lead to unexpected behavior when floating point exceptions are enabled. The library that silently enabled floating point exceptions was CGM, or rather, one of CGM's dependencies. Specifically, in a CGM built against Cubit 10.2 (with ACIS 16.0), one of the Cubit/ACIS shared libraries that CGM links to enables floating point exceptions. (I'm not sure which library it is specifically.) This does not occur when I build CGM against ACIS 16.7. So the situation is this: if I build CGM against Cubit 10.2, and then build MOAB against that CGM installation, certain MOAB functions may crash unless the calling program first disables floating point exceptions (e.g. by calling feholdexcept()). More generally, any program that enables floating point exceptions may encounter those exceptions when calling into MOAB. Is this mentioned in the MOAB documentation? ~S

4 3

r3818 - MOAB/trunk/itaps/imesh
by tautges＠mcs.anl.gov 26 Apr '10

26 Apr '10

Author: tautges Date: 2010-04-26 13:19:56 -0500 (Mon, 26 Apr 2010) New Revision: 3818 Modified: MOAB/trunk/itaps/imesh/iMesh_MOAB.hpp MOAB/trunk/itaps/imesh/testc_cbind.c Log: Bug fix: iMesh convention states that for inout arrays, EITHER null array ptr or zero alloc'd size indicates iMesh function should allocate array space; only null array ptr was being checked before. Also adding a test that checks this behavior. Modified: MOAB/trunk/itaps/imesh/iMesh_MOAB.hpp =================================================================== --- MOAB/trunk/itaps/imesh/iMesh_MOAB.hpp 2010-04-26 16:31:58 UTC (rev 3817) +++ MOAB/trunk/itaps/imesh/iMesh_MOAB.hpp 2010-04-26 18:19:56 UTC (rev 3818) @@ -135,7 +135,7 @@ int val_size, int* err ) : arrayPtr(0) { - if (!*array_ptr) { + if (!*array_ptr || !array_allocated_space) { *array_ptr = std::malloc(val_size * count); array_allocated_space = array_size = count; if (!*array_ptr) { Modified: MOAB/trunk/itaps/imesh/testc_cbind.c =================================================================== --- MOAB/trunk/itaps/imesh/testc_cbind.c 2010-04-26 16:31:58 UTC (rev 3817) +++ MOAB/trunk/itaps/imesh/testc_cbind.c 2010-04-26 18:19:56 UTC (rev 3818) @@ -86,6 +86,9 @@ return FALSE; } +#define CHK(err) if (err != iBase_SUCCESS) \ + do {printf("%s:%d ITAPS error %d\n",__FILE__,__LINE__,err); return 0;} while (0) + static iBase_EntitySetHandle root_set; /*! @@ -2171,8 +2174,6 @@ return 1; } -#define CHK(err) if (err != iBase_SUCCESS) \ - do {printf("%s:%d ITAPS error %d\n",__FILE__,__LINE__,err); return 0;} while (0) static int ordered_set_regression( iMesh_Instance mesh ) { double coords[] = { 0,0,0, 1,1,1 }; @@ -2202,6 +2203,63 @@ return 1; } +int array_allocation( iMesh_Instance mesh ) +{ + int err; + + double coords[] = { 0,0,0, 1,1,1, 2,2,2, 3,3,3 }; + + iBase_EntityHandle *verts = NULL; + int verts_alloc = 0,verts_size; + + iMesh_newMesh("",&mesh,&err,0);

2 1

r3819 - MOAB/trunk/src/io
by smithrm＠mcs.anl.gov 26 Apr '10

26 Apr '10

Author: smithrm Date: 2010-04-26 13:23:56 -0500 (Mon, 26 Apr 2010) New Revision: 3819 Modified: MOAB/trunk/src/io/ReadNCDF.cpp Log: o Added 3 NULL return checks in read_exodus_header(). Fixes ticket #6. Modified: MOAB/trunk/src/io/ReadNCDF.cpp =================================================================== --- MOAB/trunk/src/io/ReadNCDF.cpp 2010-04-26 18:19:56 UTC (rev 3818) +++ MOAB/trunk/src/io/ReadNCDF.cpp 2010-04-26 18:23:56 UTC (rev 3819) @@ -371,7 +371,12 @@ // get the word size, scalar value NcAtt *temp_att = ncFile->get_att("floating_point_word_size"); - if (!temp_att->is_valid() || temp_att->type() != ncInt || temp_att->num_vals() != 1) { + if (NULL == temp_att || !temp_att->is_valid()) { + readMeshIface->report_error("ReadNCDF:: Problem getting floating_point_word_size attribute."); + delete temp_att; + return MB_FAILURE; + } + if (temp_att->type() != ncInt || temp_att->num_vals() != 1) { readMeshIface->report_error("ReadNCDF:: Word size didn't have type int or size 1."); return MB_FAILURE; } @@ -380,7 +385,12 @@ // exodus version temp_att = ncFile->get_att("version"); - if (!temp_att->is_valid() || temp_att->type() != ncFloat || temp_att->num_vals() != 1) { + if (NULL == temp_att || !temp_att->is_valid()) { + readMeshIface->report_error("ReadNCDF:: Problem getting version attribute."); + delete temp_att; + return MB_FAILURE; + } + if (temp_att->type() != ncFloat || temp_att->num_vals() != 1) { readMeshIface->report_error("ReadNCDF:: Version didn't have type float or size 1."); return MB_FAILURE; } @@ -403,7 +413,12 @@ // title char *title = new char[max_line_length+1]; temp_att = ncFile->get_att("title"); - if (temp_att->is_valid() && temp_att->num_vals() == 1) { + if (NULL == temp_att || !temp_att->is_valid()) { + readMeshIface->report_error("ReadNCDF:: Problem getting title attribute."); + delete temp_att; + return MB_FAILURE; + } + if (temp_att->num_vals() == 1) { char *dum_str = temp_att->as_string(0); strcpy(title, dum_str); delete dum_str;

1 0

r3817 - MOAB/trunk/src
by smithrm＠mcs.anl.gov 26 Apr '10

26 Apr '10

Author: smithrm Date: 2010-04-26 11:31:58 -0500 (Mon, 26 Apr 2010) New Revision: 3817 Modified: MOAB/trunk/src/Core.cpp Log: o Added check to merge_entities verifying the 2 entities to merge are not the same entity. Modified: MOAB/trunk/src/Core.cpp =================================================================== --- MOAB/trunk/src/Core.cpp 2010-04-26 01:49:54 UTC (rev 3816) +++ MOAB/trunk/src/Core.cpp 2010-04-26 16:31:58 UTC (rev 3817) @@ -2113,6 +2113,10 @@ { if (auto_merge) return MB_FAILURE; + // The two entities to merge must not be the same entity. + if (entity_to_keep == entity_to_remove) + return MB_FAILURE; + // The two entities to merge must be of the same type EntityType type_to_keep = TYPE_FROM_HANDLE(entity_to_keep);

1 0

r3810 - MOAB/trunk/src
by iulian＠mcs.anl.gov 23 Apr '10

23 Apr '10

Author: iulian Date: 2010-04-23 13:34:41 -0500 (Fri, 23 Apr 2010) New Revision: 3810 Modified: MOAB/trunk/src/Core.cpp Log: coords array in get_coords needs to be incremented for every subrange the old pointer arithmetic is faster, but maybe BG/P will choke Modified: MOAB/trunk/src/Core.cpp =================================================================== --- MOAB/trunk/src/Core.cpp 2010-04-23 16:58:55 UTC (rev 3809) +++ MOAB/trunk/src/Core.cpp 2010-04-23 18:34:41 UTC (rev 3810) @@ -770,6 +770,7 @@ coords[3*j+1] = y[j]; coords[3*j+2] = z[j]; } + coords=&coords[ 3*count ]; } return MB_SUCCESS;

1 0

r3809 - MOAB/trunk/src/moab
by kraftche＠cae.wisc.edu 23 Apr '10

23 Apr '10

Author: kraftche Date: 2010-04-23 11:58:55 -0500 (Fri, 23 Apr 2010) New Revision: 3809 Modified: MOAB/trunk/src/moab/Interface.hpp Log: better documentation for 'file_set' parameter of Interface::load_file Modified: MOAB/trunk/src/moab/Interface.hpp =================================================================== --- MOAB/trunk/src/moab/Interface.hpp 2010-04-23 16:56:57 UTC (rev 3808) +++ MOAB/trunk/src/moab/Interface.hpp 2010-04-23 16:58:55 UTC (rev 3809) @@ -198,8 +198,10 @@ * file format. * *\param file_name The location of the file to read. - *\param file_set Output: a handle to a new set containing all entities - * read or imported from the file. + *\param file_set If non-null, this argument must be a pointer to + * a valid entity set handle. All entities read from + * the file will be added to this set. File metadata + * will be added to tags on the set. *\param options A list of string options, separated by semicolons (;). * See README.IO for more information. Options are typically * format-specific options or parallel options. If an @@ -216,6 +218,14 @@ * only those entities or sets that have a value for * the tag that is one of the values in this array. *\param num_set_tag_values The length of set_tag_values. + * + *\Note file_set is passed by pointer rather than by value (where a + * zero handle value would indicate no set) so as to intentionally + * break compatibility with the previous version of this function + * because the behavior with respect to the file set was changed. + * The file_set is now an input-only argument. The previous + * version of this function unconditionally created a set and + * passed it back to the caller via a non-const reference argument. */ virtual ErrorCode load_file( const char* file_name, const EntityHandle* file_set = 0,

1 0

r3807 - in MOAB/trunk/src: . moab
by hongjun＠mcs.anl.gov 23 Apr '10

23 Apr '10

Author: hongjun Date: 2010-04-23 11:18:45 -0500 (Fri, 23 Apr 2010) New Revision: 3807 Modified: MOAB/trunk/src/GeomTopoTool.cpp MOAB/trunk/src/moab/GeomTopoTool.hpp Log: o Obb tree construction function for geometry is added o Tree roots for surfaces and volumes are constructed Modified: MOAB/trunk/src/GeomTopoTool.cpp =================================================================== --- MOAB/trunk/src/GeomTopoTool.cpp 2010-04-23 16:16:18 UTC (rev 3806) +++ MOAB/trunk/src/GeomTopoTool.cpp 2010-04-23 16:18:45 UTC (rev 3807) @@ -33,6 +33,18 @@ // be listed for both the forward and reverse slots. const char GEOM_SENSE_TAG_NAME[] = "GEOM_SENSE_2"; +GeomTopoTool::GeomTopoTool(Interface *impl, bool find_geoments) + : mdbImpl(impl), obbTree(impl), sense2Tag(0), oneVolRootSet(NULL) +{ + ErrorCode result = mdbImpl->tag_create(GEOM_DIMENSION_TAG_NAME, 4, + MB_TAG_SPARSE, geomTag, NULL); + if (MB_SUCCESS != result && MB_ALREADY_ALLOCATED != result) { + std::cerr << "Error: Failed to create geometry dimension tag." << std::endl; + } + + if (find_geoments) find_geomsets(); +} + ErrorCode GeomTopoTool::set_sense( EntityHandle surface, EntityHandle volume, bool forward ) @@ -90,16 +102,10 @@ ErrorCode GeomTopoTool::find_geomsets(Range *ranges) { - //Tag geom_tag; - ErrorCode result = mdbImpl->tag_create(GEOM_DIMENSION_TAG_NAME, 4, - MB_TAG_SPARSE, geomTag, NULL); - if (MB_SUCCESS != result && MB_ALREADY_ALLOCATED != result) - return result; - // get all sets with this tag Range geom_sets; - result = mdbImpl->get_entities_by_type_and_tag(0, MBENTITYSET, &geomTag, NULL, 1, - geom_sets); + ErrorCode result = mdbImpl->get_entities_by_type_and_tag(0, MBENTITYSET, &geomTag, NULL, 1, + geom_sets); if (MB_SUCCESS != result || geom_sets.empty()) return result; @@ -114,14 +120,16 @@ return MB_SUCCESS; } -ErrorCode GeomTopoTool::construct_obb_trees() +ErrorCode GeomTopoTool::construct_obb_trees(bool make_one_vol) { + ErrorCode rval; +

1 0

r3806 - MOAB/trunk/itaps/imesh
by smithrm＠mcs.anl.gov 23 Apr '10

23 Apr '10

Author: smithrm Date: 2010-04-23 11:16:18 -0500 (Fri, 23 Apr 2010) New Revision: 3806 Modified: MOAB/trunk/itaps/imesh/iMesh_MOAB.cpp MOAB/trunk/itaps/imesh/testc_cbind.c Log: Fixes for MOAB Trac Ticket #160: o Added check of tag_values_size parameter in iMesh_setArrData. o Fixed test that was passing wrong tag_values_size in vertex_int_tag_test. Modified: MOAB/trunk/itaps/imesh/iMesh_MOAB.cpp =================================================================== --- MOAB/trunk/itaps/imesh/iMesh_MOAB.cpp 2010-04-22 23:29:30 UTC (rev 3805) +++ MOAB/trunk/itaps/imesh/iMesh_MOAB.cpp 2010-04-23 16:16:18 UTC (rev 3806) @@ -1913,6 +1913,17 @@ RETURN(iBase_SUCCESS); } + int tag_size; + iMesh_getTagSizeBytes(instance, tag_handle, &tag_size, err); + // Check err manually and just return if not iBase_SUCCESS to not step on + // the error set in iMesh_getTagSizeBytes(). + if (iBase_SUCCESS != *err) + return; + + if (tag_values_size != (tag_size * entity_handles_size)) { + ERROR(iBase_INVALID_ARGUMENT,"iMesh_setArrData: bad tag_values_size passed."); + } + ErrorCode result = MBI->tag_set_data(TAG_HANDLE(tag_handle), CONST_HANDLE_ARRAY_PTR(entity_handles), entity_handles_size, Modified: MOAB/trunk/itaps/imesh/testc_cbind.c =================================================================== --- MOAB/trunk/itaps/imesh/testc_cbind.c 2010-04-22 23:29:30 UTC (rev 3805) +++ MOAB/trunk/itaps/imesh/testc_cbind.c 2010-04-23 16:16:18 UTC (rev 3806) @@ -1320,7 +1320,7 @@ /* put a value in the first vertex and retrieve */ iMesh_setArrData(mesh, &dum_vert, 1, *int_tag, - (const char*)(&dum_val), sizeof(iBase_EntityHandle), &result); + (const char*)(&dum_val), sizeof(int), &result); if (iBase_SUCCESS != result) { printf("Failed to set int tag (val=11) in vertex_int_tag_test.\n"); return FALSE;

1 0

Comparing entities
by smithrm-mcs＠zimbra.anl.gov 22 Apr '10

22 Apr '10

To determine if 2 EntityHandles point to the same Entity is it valid to compare the EntityHandles by just doing an '==' check? Do I need to do a deeper comparison? --Bob Sent from my Verizon Wireless BlackBerry

2 1