Topic:
Project Upgrade Preparation: IESX 10.x to GeoFrame 3.5 through 3.7.1  

Description:
Brief guide to upgrading from IESX 10.x to GeoFrame 3.5 through 3.7.1.

Solution:
ENVIRONMENTAL CONCERNS

1.)  Both the IESX 10.x and GeoFrame 3.5 software must be loaded.
 
2.)  To upgrade IESX 10.x to GeoFrame, IESX and GeoFrame must use the same
     $IESX_CONFIG.

     To check this:
     In an IESX xterm launched from GeoNet type:   echo $IESX_CONFIG

     In a GeoFrame xterm launched from GeoNet type:   echo $IESX_CONFIG

If they are different and no projects currently exist in GeoFrame:

    Edit the following GeoFrame file:

    $GF_HOME/iesx/iesx_setup_site.csh

     Look for the following line and edit the config path to the complete
     pathname received from $IESX_CONFIG in the IESX xterm.
     =>  setenv $IESX_CONFIG /home/gqs/iesx_config/

If they are different and projects do currently exist in GeoFrame, consult 

    'How to upgrade IESX 10.x to GeoFrame with different $IESX_CONFIG files'.


PROJECT CONCERNS

1.)  The IESX project must be at the 10.1 or above release level and the
     project preparation should be performed at this level.
 
2.)  Once a project is upgraded to GeoFrame 3.5, it is no longer available in
     IESX 10.x. If the user desires a working copy of both the IESX 10.x
     project and the GeoFrame 3.5 projects, it is recommended that a copy of
     the 10.x project be created before an upgrade is attempted.  Create a
     copy of the 10.x project using the Rename utility.  Customer Support
     strongly suggests that the rename option available on the `Upgrade IESX10.1
     Project' menu not be used because this option will rename the project in
     the Oracle data base, but the original project name is retained in the
     IESX GeoFrame 3.5 database and will cause problems later if the user wants
     to patch in their original IESX 10.x project.

PREPARATION
 
1.)  Before the upgrade is attempted, make a current backup of the IESX 10.x
     project or create a clone of the project.
 
2.)  Open permissions to rwxrwxrwx on all the directory/files in the 10.x
     project.
 
3.)  Always unshare all clones from the master 10.x project prior to the
     upgrade.
  -  If you cannot unshare there is an unshare option in the upgrader
     that will unshare the shared references for you, Customer Support
     recommends to unshare before upgrading.
  -  To get a report of what data is shared in a clone project (outgoing
     references) run option 73 in the IESX Utilities.  This will show the 
     paths to the data the clone project is sharing (10.2 option only). 
     If you have 10.1 and are not planning on installing 10.2, then use 
     option 45; this will list the projects it is shared to.
 
4.)  If any markers reside in the IES database import them to IESX using
     DataManager > Markers > Import from IES.

5.)  Check for marker associations in Markers > Manage Formations. Look for
     markers that are associated to the same seismic surface and disassociate
     these. In GeoFrame, the data model does not allow for multiple formations
     to be assocatied with the same geophysical surface.

6.)  In MapView or IES Data Management, delete any XYZ, contour or grid files
     that you don't need. These files will be converted to Oracle and take
     extra time during the upgrade process.
 
7.)  Clean up any survey descriptions and any byte zero problems by using
     IESX_Util option 5.
 
8.)  Check for any missing files by using option 41 (Check inventory files)
     in the IESX_Utils.
 
9.)  Delete any duplicate fault contacts and/or fault cuts or traces using
     IESX_Util options 23, 24, and 25.


CONSIDERATIONS

1.)  Suggested upgrade sequence:
     -Master projects first 
     -Clone or shared projects second 
     Master and clones cannot be upgraded simultaneously.

2.)  Typically in a project upgrade, the problem areas are well data, mapping
     data, and interpretation.  Upgrade of seismic data and interpretation 
     data should be virtually pain free because it just makes pointers in the
     ORACLE database and the bulk files are not touched.  Preparation and
     cleaning up of the wells, mapping data and interpretation data types,
     prior to upgrade, will improve speed and decrease probability of failure.

3.)  It is recommended for speed purposes, the workstation have at least 1 gig
     of swap and 1 gig of RAM on the machine doing the upgrade.

The following is an overview of what will happen to each data type during the
upgrade (in order of most time taken to least).

a.)  Wells - are exported to a temporary area from IESX (defined in the
     'Temporary work directory' of the upgrade dialog box).  New wells and
     boreholes are created in Oracle and this data is imported into GeoFrame
     3.5.  New files/directories will be created in the Default DSL.
 
b.)  Markers - are exported to a temporary area from IESX (defined in the
     'Temporary work directory' of the upgrade dialog box). When imported into
     GeoFrame a surface will be created for each marker name (i.e. effectively a
     horizon for every marker name).  The link between existing horizon names
     and marker names will be lost unless they are identical.  The surface
     created from a marker will be a `geological horizon'.  If markers exist for
     faults they will be upgraded as `surfaces'.

c.) Mapping Data - (grids, contours, scatter sets and MapView fault traces).
    These data types are exported to the temporary area from IESX (defined in
    the 'Temporary work directory' of the upgrade dialog box) and are later
    imported and converted to Oracle for use in Basemap+. These new files will
    be stored in the Default DSL. If CPS-3 DSLs are defined for the project
    after the upgrade, such files would go there when added.

4.) Count on up to 10% of the project data converting to Oracle.


UPGRADE MENU PROCEDURE

Select GeoFrame 3.5 from Geonet, and click on 'Upgrade IESX 10.x Project'.

Project Name               Project name of 10.x project.

Project Password           Password of 10.x project.

Temporary work directory   Default is $HOME if not specified. Type in a path to
                           a disk that has at least 2 gig. Do not use /tmp.

Continue on bad data       Default is 'No'.
                           Upgrade will at the end of Stage 2 if 'bad data' is
                           detected, eg. 1 point well path.
                           Recommend using 'No' as it doesn't take long to check
                           the data and gives you the chance to fix it if
                           required, before restarting the upgrade.
                           If set to 'Yes' it will automatically drop 'bad data'
                           and proceed with the upgrade. 
                           The log file records which data is dropped.

Unshare                    Default is 'No'.
                           If set to 'No, stops at stage 1 if any shared
                           references exist. Recommend unsharing data in 10x
                           before upgrade.Use 'Yes' only if share references are
                           corrupt or data cannot be unshared via datamanager or
                           iesx_util.

Resume                     Default is 'No'.
                           Only set to 'Yes' if upgrade fails and gives specific
                           instructions to restart using 'resume'.

Rename                     Leave blank. Not recommended.

Replacement Ellipsoid Code Leave blank. Enter a replacement projection ellipsoid
                           if IESX 10.x spheroid is user-defined. Refer to
                           upgrade documentation to find out if you need a
                           replacement code.

Select OK to begin upgrade process.


POST UPGRADE

1.)  The DSL naming convention in GeoFrame 3.5 is different to that of IESX
     standalone (10.x and below), i.e. /disk/geoframe_dsl/ACCOUNTNAME/dsltype.

          Examples:     /disk1/gf_root/PROJECT_X/Default/
                        /disk1/gf_root/PROJECT_X/Seismic/
                        /disk1/gf_root/PROJECT_X/Interpretation/


Data upgraded from IESX 10.x does not fit the new DSL naming convention. 

Examples: /disk1/gf_root/project_name  will upgrade to
          /disk1/gf_root/PROJECT_NAME (this is the account name).


2.)  Borehole appearance sets and Map appearance sets are lost in the upgrade
     process due to upgrades to the appearance sets in GeoFrame.

3.)  A log file is created in the users $HOME directory showing each upgrade
     stage.  It also shows the start and end time of the upgrade so you can
     see how long the process actually ran. The log file is named,
     "upgrade_10_gf_project_name_time_stamp.log", this is a good file to look
     at because it logs any problems that the upgrade may have had.

4.)  To see how much space the project took up in Oracle, type in a GeoFrame
     xterm: space_check system/manager

5.)  Check project integrity by running the Quality Control Tool from either
     Application Manager > Data Manager > Tools or General Data Manager and 
     select the 'red cross' icon. This tool is designed to find and repair data 
     or parameters that are invalid, missing, incomplete, incorrectly loaded,
     or improperely associated with other data. You can run the report on
     individual data items on all the data in the project. A report is generated
     which is saved in the project and the user can then decide whether to
     manually repair the data items or use the auto-repair feature. Select
     the 'Help' icon on each menu for more details on this tool.






Last Modified on: 22-MAY-00