Lawrence Livermore National Laboratory



February 20, 2009

Silo has a smaller tarball for 4.7 now available for your use. Here is a smaller silo-4.7-smalltest.tar.gz tarball to use.


January 15, 2009

Obtain source code here: https://wci.llnl.gov/content/assets/docs/simulation/computer-codes/silo/silo-4.7/silo-4.7.tar.gz

Obtain documentation here: https://wci.llnl.gov/content/assets/docs/simulation/computer-codes/silo/LLNL-SM-410226.pdf

Organization of information in this announcement.

  1. New features in this release
  2. Bugs fixed in this release
  3. Details regarding API change for datatype'd pointers
  4. Other general information

A. New features in this release

  • The API was modernized in places where the datatype of an array is specified using 'int datatype' to use 'void*' in place of 'float*'.
  • This API change may be 'turned off' at configure time and will otherwise lead to compiler errors requiring the client to correctly cast a pointer. Read item C, below for more details.
  • A majority of the test suite now compiles and runs on Windows. Thanks to Kathleen Bonnell for doing this.
  • Namescheme functions were added to support on-demand generation of names of arrays of sets in mrgtrees.
  • Version info functions were added to obtain and/or compare versions of the library the executable is linked with as well as versions of the library a given file was created with.
  • Example files and source code for using Silo for block-structured AMR meshes in 2D and 3D have been developed.
  • silodiff now supports diff'ing directories as well as making it easy and less error prone to diff a file with another by the same name in a different directory.
  • silex was was ported to (and now requires) Qt-4. Thanks to Jeremy Meredith for doing this.
  • User's manual was updated to match the current, 4.7 API.

B. Bugs fixed in this release.

  • The DBOPT_TOPO_DIM option for ucd meshes was being handled incorrectly defaulting always to set topological dimension to be equal to spatial dimension.
  • A user reported 'db_close' public symbol name collides with BRL/CAD making it impossible to link the two in the same application. That symbol name was changed.
  • Numerous tests failed to compile on windows due to large allocations of local variables. Those have been fixed.
  • Mrgtrees were not handling sets defined with nameschemes correctly. Attempting to write an Mrgtree using nameschemes was causing a segv. That has been fixed.
  • Mrgtrees with nameschemes could not be read correctly. That is fixed.
  • Groupel maps with implicit segment ids were causing segvs. Those have been fixed.
  • Attempting to write Mrgtree variables (mrgvars) with regions involving nameschemes would segv. Those have been fixed.
  • PutMultimeshadj was writing nodelist information to its zonelist member. Thanks to Sean Ahern for fixing this.
  • Improved output from browser for mrgtrees.
  • Fixed bug in browser output causing extraneous extra blank lines to be output as well as line splitting of arrays of strings that would otherwise fit on a single line.
  • Fixed bug in silex preventing it from displaying certain components of objects and spewing error messages to stderr about it.
  • A number of leaks in the PDB driver were fixed and more extensive leak testing was performed.

C. Details of API changes from 'float *' to 'void *'

First, have no fear, if you REALLY DON'T WANT TO DEAL WITH THIS, then just make sure you configure Silo with --enable-legacy-datatyped-pointers.

It has been a source of confusion to many users of Silo for many years that functions like DBPutUcdmesh accept an 'int datatype' argument to specify the datatype of the coordinate arrays but than the coordinate arrays themselves are specified as 'float *coords[]' in the API. Users either discovered on their own or asked Silo developers if it is OK to pass pointers to arrays other than float. Indeed, it has been. The same has also been true of the struct objects that Silo returns in its read interface. For example a DBucdmesh object contains an 'int datatype' member to indicate the datatype of the 'coords' member. However, the coords member type was still float* leading to still other confusion when trying to read Silo data. This problem has existed throughout most of the older functions and objects of Silo's API but has been avoided with newer functions and objects by appropriate use of 'void*'. Nonetheless, this behavior for older functions and objects has often led to questions that would have to be fielded by Silo developers.

Starting in version 4.7, all these cases have been 'modernized' to use 'void *'. But, this can be controlled during configuration of the Silo library using the --enable-legacy-datatyped-pointers. This way, if you are comfortable using the old (legacy) conventions, you are free to continue doing so. Support for this will never be removed from the Silo library. However, new users of Silo will most likely compile Silo without this option and experience a less confusing interface. Regardless, the Silo User's manual documents only the modernized interface.

Note that the effect of these API changes are confined primarily to the read half of Silo's interface. So, if you are simply writing Silo files but not reading them, you should experience no errors. Furthermore, on the read half of the interface, the issues you will encounter are compiler errors when you access a void* data member of a Silo object without properly casting it to the desired type, which is specified by an associated 'int datatype' member of the object. Also, since any application reading double precision data would have had to deal with this already to avoid compiler warnings in assigning float* to double*, and since those warnings will become outright errors, the cases that need any attention to be made compliant with the modernized API should be obvious and easily corrected.

D. Other general information

Silo 4.7 is NOT link-time compatible with any previous versions. To use it, you will need to re-compile any Silo client code.