Product Name: TIBCO OpenSpirit Data Connector for OpenWorks v2.5.1
Release Version: 2.5.1_HF03
Release Date: Apr 2020

================================================================================

TIBCO OpenSpirit Data Connector for OpenWorks v2.5.1 HF03 is a patch version of the
OpenWorks Data Connector. The data connector package ("OpenWorks_v2_5_1_203.osp_pkg")
needs to be imported and installed like any other data connector update.

NOTE: OpenSpirit Runtime version v4.3.0-HF03 is required to be installed before
      installing this fata connector update.

This is a cumulative hotfix.

HF03 includes fixes for issues:
-------------------------------------
 - Issue OSPOW-361 - Fixed a problem where the horizon values were not being properly
                     adjusted to the seismic reference datum when updating a depth 2d horizon.
 - Issue OSPOW-358 - Fixed problem that could occur in a Copy Manager workflow where the
                     user has no access to any interpreter in the target data store, which
                     would cause the data connector to hang.
 - Issue OSPOW-331 - Corrected a data connector hang problem while retrieving the PickColor
                     attribute when the pick had no associated PickColor in OpenWorks.
 - Issue OSPOW-343 - Fixed problem inserting Picks under specific data conditions.
 - Issue OSPOW-347 - Fixed EPOS to OpenWorks copy rules related to setting interpreter to
                     an empty string.
 - Issue OSPOW-334 - Display a WARNING message in the OpenWorks data connector log file if
                     a point set has over 500,000 points and with enough information to identify
                     the point set. This will help OpenSpirit Support identity potential memory
                     problems in without requiring clients to rerun their workflow in debug mode.

HF02 includes fixes for issues:
-------------------------------------
 - Issue OSPOW-324 - Changed exception message from " insufficient access privilege"
                     to "insufficient access privilege; might be due to an invalid
                     Oracle password; please use native Landmark launcher and set
                     valid oracle password"
 - Issue OSPOW-325 - Fix performance problem introduced in v2.5.1 HF01 when reading the
                     OpenWorks surfaces. Fix a ConcurrentModificationException also
                     introduced in v2.5.1 HF01 when reading surfaces if the client
                     application is multi-threaded (e.g. CopyMgr).

HF01 includes fixes for issues:
-------------------------------------
 - Issue OSPOW-321 - Drastically improved the DataSelector performance when displaying all the
                     Horizon and Fault Point Set data if only the default attributes are selected.
 - Issue OSPOW-319 - Fixed insert/update problems with EpiInterpretation_HorizonPointSetProperty and
                     FaultPointSetProperty FloatProperty and DoubleProperty if using Float/Double NaN
                     for the null value representation in either the quantity series null value or the
                     NullValue attribute.
 - Issue OSPOW-317 - Fixed the error message so it contains more information if trying to insert into
                     an IP project and a gdiAdd error occurs. It could be due to the spatial XY data
                     being outside the IP project's Area of Interest.
 - Issue OSPOW-316 - No longer returning twice the number of EarthModel rows when querying against
                     the EarthModel table and specifying more than one EarthModel data key in the
                     WHERE clause. This was also a problem when using DataSelector and scoping
                     the 2d/3d seismic horizons or faults based on the EarthModel and more than one
                     EarthModel row was selected.
 - Issue OSPOW-315 - Avoid NullPointerException with specific workflows when validating an OpenWorks
                     interpreter.
 - Issue OSPOW-314 - Added additional diagnostics to the OpenWorks server script to improve messaging
                     when there is an issue with the Oracle wallet directory.
 - Issue OSPOW-313 - No longer retrieving all the point set XYZ data if client requested
                     the EpiInterpretation_HorizonPointSet's NumPoints attribute and not the Points
                     attribute. This increases performance and decreases the amount of memory required
                     for the query. This is a revert of OSPOW-279  introduced in 2.5.1.
 - Issue OSPOW-312 - Fixed problems associated with exporting many stratigraphic columns and units from
                     Petrel/TOAP to OpenWorks.
 - Issue OSPOW-311 - Fixed OutOfMemory problems when clients had a very large amount of point sets and/or
                     some of the point sets contained tens to hundreds of thousands of points. This was a
                     problem when they tried to send all the point sets in an OpenWorks project to Petrel
                     or if they used the DataSelector, turned on the 'Points' attribute, and listed all
                     the point sets in the OpenWorks project.
 - Issue OSPOW-310 - The OpenWorks data connector is now using -Xmx4000m (4GB) instead of -Xmx3000m (3GB)
                     to avoid OutOfMemory errors when running queries that return a lot of data.
 - Issue OSPOW-309 - Fixed problems when inserting into the EpiInterpretation_Horizon table and the Name
                     exceeds 40 characters. The OpenWorks database has a maximum length of 40 characters
                     for surface names.
 - Issue OSPOW-308 - The EpiInterpretation_HorizonPointSetProperty and EpiInterpretation_FaultPointSetProperty
                     tables now return the MinValue and MaxValue if the min/max is not populated in the
                     OpenWorks database but the properties have valid numeric array values.
 - Issue OSPOW-307 - OpenSpirit now creates XY rotated non-seismic grids like DecisionSpace (DSG) so
                     the DSG viewer can display the rotated grids in the correct geographic location.
                     DSG viewer has problems displaying the rotated grids if the rotation origin is the
                     lower-left corner even though that is a valid way of creating the rotated grids.
 - Issue OSPOW-304 - Fixed a problem when inserting into the EpiInterpretation_HorizonGrid2dProperty table
                     (only for non-seismic grids) and using a FeatureRepresentation data key that represents
                     an existing non-seismic grid in the OpenWorks database. The non-seismic grid will now be
                     created instead of getting an exception saying that 'data_source' is required but it is null.
 - Issue OSPOW-302 - The EpiSeismic_LineGeometry2d and EpiSeismic_PostStack2d XY (LineString) is now returned
                     with a Local CoordinateReferenceSystem (CRS) if there is a problem with converting the
                     2d line's original crs id into an OpenSpirit CRS. Previously, the XY was tagged with the
                     OpenWorks project's storage CRS which could be completely wrong and cause the 2d line
                     to show up in the wrong geographic location.
 - Issue OSPOW-301 - The EpiInterpretation_HorizonGrid2d Extent, CoordinateSystem, and CoordinateSystemName
                     attributes are no longer returned as null if a query is run against the HorizonGrid2d
                     table before doing the insert into the HorizonGrid2dProperty table. This was only a
                     problem when creating non-seismic grids. This was not a problem when creating seismic horizons.
 - Issue OSPOW-299 - A WARNING message is now written to the DC-OpenWorks log file if it encounters
                     a 2d line (EpiSeismic_LineGeometry2d) or 2d dataset (EpiSeismic_PostStack2d) that
                     has more than 20,000 traces. This does not change the DC-OpenWorks behavior in any
                     way and is only being done as a potential explanation if the DC-OpenWorks is running
                     out of memory when processing seismic 2d data. For example, if there is some "bad"
                     data in the database and the computation for number of traces results in a very large
                     number. OpenSpirit allocates memory for returning arrays of shotpoints, cdp, XY, and
                     trace values so if the number of traces is huge then it might run out of memory when the
                     memory is being allocated.
 - Issue OSPOW-297 - OpenSpirit was not returning the EpiInterpretation_HorizonGrid2dProperty's (non-seismic)
                     DataExtent correctly for some XY rotated grids if the grid was created without
                     setting the xbar/ybar values. The xbar/ybar identify the rotation origin and some
                     native OpenWorks applications do not populate them. OpenSpirit was incorrectly
                     using xbar/ybar values of -98765 in this scenario because that is what OpenWorks
                     returns to denote an uninitalized attribute. OpenSpirit now correctly recognizes if
                     the xbar/ybar values are uninitialized and will interpret this as a rotation origin
                     of (0, 0) so the four corners of the DataExtent are now computed correctly.
 - Issue OSPOW-296 - OpenWorks point sets (EpiInterpretation_HorizonPointSet) and
                     non-seismic grids (EpiInterpretation_HorizonGrid2dProperty) with
                     a data_domain of TVD are now identified as a primary Z surface and
                     can be sent to OpenSpirit applications (e.g. Petrel/TOAP) and viewed as
                     a primary Z surface. This change was made because some customer projects are
                     onshore and the data has been loaded with a TVD data domain instead of TVDSS.
 - Issue OSPOW-295 - Horizon and fault point sets (EpiInterpretation_HorizonPointSet and
                     EpiInterpretation_FaultPointSet) XY spatial data is now properly coordinate
                     converted when writing to an OpenWorks project that has a different
                     Coordinate Reference System (CRS). Previously the XY spatial data was only
                     unit converted so if the CRS did not match the point set spatial data was
                     not in the correct geographic location.
 - Issue OSPOW-293 - All OpenWorks point sets will be returned as rows in the OpenSpirit
                     EpiInterpretation_HorizonPointSet table as long as the geo_type
                     attribute is not "FAULT". Previous to this change the only point
                     sets returned as HorizonPointSet had a geo_type of "SURFACE" or
                     "STRAT_UNIT". This change was made because some customers had
                     geo_type values of "OTHER" and their point sets were not visible
                     using OpenSpirit tools.

.========================================================

NOTE: See attached Readme document for installation instructions.

TIBCO OpenSpirit Data Connector for OpenWorks v2.5.1 HF03 is available

All supported environments

The hotfix can be downloaded from the TIBCO Support Customer Portal Web UI,
using your username and password for the TIBCO Support Web.

Once logged on the hotfix can be found under the Downloads Menu:
AvailableDownloads/OpenSpirit/DataConnectors/OpenWorks/2.5.1/HF03

 

OpenWorks_DC_v251_HF03.txt