
#------------------------------------------------------------
#
#     ,o, ,o,       /                                 
#      `   `  e88~88e  d88~\   /~~~8e Y88b    e    / 
#     888 888 88   88 C888         88b Y88b  d8b  /   
#     888 888 "8b_d8"  Y88b   e88~-888  Y888/Y88b/  
#     888 888  /        888D C88   888   Y8/  Y8/     
#     88P 888 Cb      \_88P   "8b_-888    Y    Y    
#   \_8"       Y8""8D                             
#
#------------------------------------------------------------
#   JIGSAW: an unstructured mesh generation library 
#------------------------------------------------------------

  * Version 0.9.14:
    --------------

  - Improved "float-preserving" I/O: print using C-
    style "%.17g" format to ensure all double-prec.
    bits are written.

  - Fix a precision-bug in the aabb-tree splitters.

  - Revisions to the edge-"zip"/"div" optimisation
    predicates.


  * Version 0.9.13:
    --------------

  - Better support for robust geometric computation 
    using multi-precision floating-point operators.

  - Initial support for "mixed-cell" mesh complexes
    enabling (limited) processing of tria/quad/hexa 
    mesh formats.


  * Version 0.9.12:
    --------------

  - Support for "gradient-limiting" of mesh-spacing
    data via the cmd-line utility MARCHE. This tool 
    solves a variant of the Eikonal equation

    MAX(|dh/dx|,g) = g,

    where g = g(x) is a gradient threshold to be 
    applied to the distribution h(x). MARCHE can be 
    used to construct smooth mesh-spacing functions 
    from noisy input data. MARCHE shares common I/O 
    protocols, options, etc with JIGSAW.

  - Optimisation of various low-level functionality
    throughout. 0.9.12.x should use less memory and 
    be slightly faster overall.

  - rDT//ODT meshing kernels will more aggressively 
    respond to user-defined mesh-spacing functions 
    that incorporate non-uniform spatial structure.

  - Support for both ODT and CVT style optimisation
    kernels. ODT should still usually be preferred. 


  * Version 0.9.11:
    --------------

  - cmake support for WIN32/64 via MSVC.


  * Version 0.9.10:
    --------------

  - Improved support for initial conditions, allow-
    ing "un-refinable" edges/faces to be specified.

  - Support for unstructured H(x) specifications on 
    the ellipsoid.


  * Version 0.9.8 :
    --------------

  - Support for "multi-part" domains and "internal"
    constraints. An additional geometry index BOUND
    can be used to define how edges/faces in the 
    domain are associated with various enclosed 
    areas/volumes, known as "parts". While the full 
    domain is (always) meshed as a conforming tess-
    ellation, individual sub-meshes for each "part" 
    can be identified via an ID tag. "Internal" 
    constraints (those that don't define the bound-
    ary of any "part") may also be specified.

  - Support for standalone generation of restricted
    Delaunay tessellations via the cmd-line utility
    TRIPOD. This tool exposes JIGSAW's internal rDT
    infrastructure, allowing restricted structures
    to be assembled given a set of points and a ge-
    omtry definition. TRIPOD shares common I/O pro-
    tocols, options, etc with JIGSAW.
 
  - Revisions to JIGSAW's core rDT predicates, ado-
    pting a "halfplane clipping" test to determine
    intersections between the dual-complex and the
    geometry. The new approach (still employing an
    "epsilon" floating-point model) should be more
    numerically robust, especially for domains with
    "sharp-features" in R^3.
 

  * Version 0.9.6 :
    --------------
    
  - Support for definition of initial distributions 
    via INIT_FILE.
  

  * Version 0.9.5 :
    --------------
    
  - Support for generalised 'regular-power' grids - 
    a 'weighted' variant of the 'standard' Voronoi-
    Delaunay tessellation that can be used to cons-
    truct very high-quality, orthogonal primal-dual 
    pairs for co-volume type numerical simulations.
    
    Regular-power grids are constructed through an
    optimisation-based approach; enabled by setting
    OPTM_DUAL=TRUE. 
    

  * Version 0.9.4 :
    --------------

  - Support for a new iterative mesh-optimisation 
    algorithm. Improvements to mesh-quality metrics
    are sought using a combination of geometrical
    and topological operations, including: topolog-
    ical 'flips', node 'smoothing', and edge/face
    'merge' and 'split' predicates.


  * Version 0.9.3 :
    --------------
    
  - Support for user-defined mesh-spacing functions
    via HFUN_FILE, allowing general mesh-size info-
    rmation to be specified on structured or unstr-
    uctured background grids.   
  

  * Version 0.9.2 :
    --------------

  - Improvements to the 2-dimensional mesh generat-
    or, including full detection and protection of
    sharp 0-dim. features included in the input ge-
    ometry. 


  * Version 0.9.1 :
    --------------
    
  - Support for topological constraints: 1-dim fea-
    tures can be forced to be 'locally 1-manifold',
    2-dim. features can be forced to be 'locally 2-
    manifold'. Constraints are enforced through ad-
    ditional refinement.
    
    See MESH_TOP1, MESH_TOP2.

  - Detection of 0- and 1-dim. features in the geo-
    metry. 
    
    Auto-detection of 0- and 1-dim. features is at-
    tempted by scanning the input geometry, enumer-
    ating any features that subtend critical angles
    and/or non-manifold topological connections.

    See GEOM_FEAT, GEOM_ETA1, GEOM_ETA2.

  - Partial support for embedded 'sharp' features:
    
    'Sharp' 0-dim. features (i.e. the apexes of any 
    small acute angles subtended by 1-dim. features
    in the geometry) are identified and enclosed in
    a set of 'protecting-balls'. This process ensu-
    res that such features are embedded in the out-
    put mesh, and preserves the convergence of the 
    refinement loop. Small angles (in violation of
    MESH_RAD2) may exist in the 'protected' region.

    'Sharp' 1-dim. features (i.e. the apexes of any
    small acute angles subtended by 2-dim. features
    in the geometry) are NOT CURRENTLY PROTECTED!
    Valid meshes are currently only produced if the  
    geometry contains surface features that meet at
    angles of greater than 60 deg. Convergence may
    be compromised otherwise. 


  * Version 0.9.0 :
    -------------- 
    
  - Initial BETA release.
  
    
    
