1. 14 Sep, 2015 1 commit
  2. 17 Dec, 2014 1 commit
  3. 29 Nov, 2014 1 commit
  4. 02 Jun, 2011 1 commit
    • 's avatar
      o Mark the following functions in Interface as deprecated: tag_create,... · 3d03edf0
      authored
      o Mark the following functions in Interface as deprecated: tag_create, tag_create_variable_length, tag_get_handle( const char*, Tag& )
      o Change all MOAB code that uses above functions to use new tag_get_handle 
      o Fix old test code in MBTest that never ran and would have failed if it did
      o Fix gttool_test always succeeded (never exited with non-zero exit code)
      o Fix mbfacet_test always succeeded (never exited with non-zero exit code)
      o Make MB_TAG_EXCL imply MB_TAG_CREAT for Interface::tag_get_handle
      o Ignore storage type (dense/sparse) if specified for bit tags in Interface::tag_get_handle
      o Match passed default value of zero with a dense tag with no default value because existing code passes that and dense tags kinda have an implicit default of zero.
      o Add flag to Interface::tag_get_handle to skip checking the default value
      
      Rational for changes to tag API:
      
      o One function for both get_handle and create because most code is fine with
        either as long as it gets the desired tag handle
      o Distinction between failure and error: callers can specify arguments to
        tag_get_handle such that either they get back MB_SUCCESS or they cannot
        continue (no more checking for other error codes such as MB_ALREADY_ALLOCATED
        that could also mean success in some cases.)
      o MOAB does type checking for tag when returning an existing tag handle.
      o Sizes specified in number of values rather than number of bytes
      
      Some examples:
      
      OLD: tag_create( name, 4*sizeof(int), MB_TAG_SPARSE, MB_TYPE_INTEGER, handle, NULL, true )
      NEW: tag_get_handle( name, 4, MB_TYPE_INTEGER, handle, MB_TAG_SPARSE|MB_TAG_CREAT )
      
      OLD: tag_get_handle( GLOBAL_ID_TAG_NAME, handle )
      NEW: tag_get_handle( GLOBAL_ID_TAG_NAME, 1, MB_TYPE_INTEGER, handle )
      
      OLD: tag_create_variable_length( name, MB_TAG_DENSE, MB_TYPE_HANDLE, handle, def_val, def_val_len*sizeof(EntityHandle) )
      NEW: tag_get_handle( name, def_val_len, MB_TYPE_HANDLE, handle, MB_TAG_DENSE|MB_TAG_VARLEN|MB_TAG_CREAT, def_val )
      
      OLD: tag_create( name, 2, MB_TAG_BIT, MB_TYPE_BIT, handle )
      NEW: tag_get_handle( name, 2, MB_TYPE_BIT, handle, MB_TAG_CREAT )
      
      
      
      git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk@4922 6162379e-bd28-0410-9a7d-b7f4dcfcad3c
      3d03edf0
  5. 29 May, 2010 1 commit
    • 's avatar
      o Change the way the subset specification is passed to readers for · 22db0f1e
      authored
         partial/parallel read.  
      o  Change some of the reader tests to go through moab::Interface 
      o  fix bug where ReadHDF5 did not compile if MOAB was configured with
         MPI support but the HDF5 library was not.
      
      The reader test changes will hopefully avoid the need to update these
      tests very time the internal reader interface changes.
      
      After trying to document the argument list I had previously defined for
      this, I came to the conclusion that it was confusing and a little bit
      non-sensical for parallel reads.  The num_parts and part_number arguments,
      if speicified, should apply to the whole list of tagged sets, rather than
      being associated with a particular tag.  Rather than document a broken
      API, I decided to fix it.  
      
      Rather than make the num_parts and part_number arguments be two more
      arguments to Reader::load_file, wrap all the arguments related to 
      partial reads in a struct and pass that as a poitner to Reader::load_file.
      This is a little more complicated, but makes sense to me for this
      particular case because the vast majority of readers don't support
      partial/parallel reads and therefore need never look at the contents
      of the struct.
      
      Most of the modified reader sources were just function signature changes.
      The only functional change was in ReadHDF5, which is the only reader that
      did anything with two arguments in question.
      
      
      
      
      
      git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk@3982 6162379e-bd28-0410-9a7d-b7f4dcfcad3c
      22db0f1e
  6. 04 May, 2010 1 commit
  7. 20 Apr, 2010 1 commit
  8. 12 Mar, 2010 1 commit
  9. 10 Mar, 2010 1 commit
  10. 09 Mar, 2010 2 commits
  11. 25 Nov, 2009 1 commit
  12. 13 Nov, 2009 1 commit
    • 's avatar
      MBInterface API and behavior change. Previously, MOAB would create a new · a60bdb3c
      authored
      entity set for each call to MBInterface::load_file, containing all entities
      read from the file.  It no longer does this (ever.)  Rather than passing
      back the handle for the (no longer created) file set from 
      MBInterface::load_file, MBInterface::load_file is now passed a 
      'const MBEntityHandle*', which may be NULL.  If it is not NULL, then
      it is assumed that the *caller* *allocated* a set, and the entities
      read from the file will be added to the passed set.  
      
      Readers are no longer responsible for adding entities to the file set,
      if there is one.  This was the case prior to this commit.  Clean up
      the remaining places where readers add entities to the passed set anyway.
      
      Update all readers such that file set is optional (even though readers
      don't put entities in the set, some still attach meta-data to the set.)
      
      Change ReadNASTRAN to use RangeMap rather than offsets with optional
      lookup by tag value.
      
      
      git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk@3343 6162379e-bd28-0410-9a7d-b7f4dcfcad3c
      a60bdb3c
  13. 12 Nov, 2009 1 commit
  14. 01 Oct, 2009 1 commit
    • 's avatar
      o Move creation of file set out of individual readers and into common · f4c70090
      authored
        code in MBCore.
      
      o Move deletion of entities when read fails part way from individual
        readers to common code in MBCore (and implement it properly.)  
      
      o ReadIDEAS: check that the call to open the file succeeds.
      
      o ReadHDF5: fix bug preventing deletion of entities if read fails.
      
      o ReadSMS: fix bug where read entities were never added to file set
      
      o ReadCGM: fix bug where no entities are added to file set,
                 remove unnecessary variables (3 copies of file name,
                 etc.)
                 
      o ReadNCDF: remove all logic related to doing special stuff with
                  file sets.  All of this belongs in higher-level code
                  if we want it at all.  Remove unnecessary variables.
      
      
      git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk@3188 6162379e-bd28-0410-9a7d-b7f4dcfcad3c
      f4c70090
  15. 24 Aug, 2009 1 commit
  16. 20 Aug, 2009 1 commit
    • Paul Wilson's avatar
      Add support for reading mesh generated for use in ABAQUS. · 0a75feda
      Paul Wilson authored
      [Note: these files typiclly use the extension ".inp"
             but that seemed to generic so I set up automatic
             support for ".abq" instead.]
      
      This mesh format implements a part/assembly/instance
      paradigm with nodes & elements collected in node sets
      and element sets.  This was implemented in MOAB using
      tags and meshsets (but no parent-child) relationships.
      For example, assembly meshsets contain instance meshsets
      and instance meshsets are tagged with the handle of the
      assembly meshset that contains them.  At the moment an 
      extensive set of cross-referencing was done with this
      general technique.  This should probably be documented
      in more detail for this implementation, but could probably
      have portions of it abstracted in order to support other
      mesh formats with a similar paradigm.
      
      At this point, the reader supports a limited set of
      keywords, largely for determining which material is
      in each mesh element.
      
      The reader also only supports a limited set of 
      ABAQUS element types, but extending for additional types
      is straightforward.  The corollary is that the purpose
      of this reader is so limited that the type of element
      rarely matters beyond mapping it onto the correct 
      MBEntityType and knowning the correct connectivity size.
      
      
      
      git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk@3114 6162379e-bd28-0410-9a7d-b7f4dcfcad3c
      0a75feda