Unix Release Notes

Landmark Desktop-VIP
VIP Simulators 2003.4

UNIX and Linux Release Notes
Landmark/Asia Pacific Landmark/EAME Landmark/The Americas

11th Floor Menara Tan & Tan Benchmark House 15150 Memorial Drive
207 Jalan Tun Razak 203 Brooklands Road Houston, Texas 77079
50400 Kuala Lumpur Weybridge, Surrey KT13 ORH U.S.A.
Malaysia England Tel: 281-560-1000
Tel: 011-60-3-264-1121 Tel: 011-44-193-282-9999 Help Desk: 281-560-1200
Fax: 011-60-3-264-1135 Fax: 011-44-193-283-2000 Fax: 281-560-1168
Help Desk: 011-61-8-9481-4488 Help Desk: 011-44-193-283-2100 Email: support@lgc.com
Email: apsupport@lgc.com Email: eame_helpdesk@lgc.com
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Enhancements and New Features . . . . . . . . . . . . . . . . . . . 15
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
LAM License Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Setting the Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
VIP 2003.3.0 UNIX/Linux Release Notes Page 1 December 2001

VIP 2003.3.0 UNIX/Linux Release Notes Page 2 December 2001

Table of Contents
Introduction
Whats New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
VIP Unix/Linux Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
System Requirements
Sun Solaris Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Tested Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Parallel Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Additional Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Additional Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
IBM AIX Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Parallel Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Additional Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Additional Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
SGI IRIX Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Unique Parallel Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Linux Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Unique Parallel Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Enhancements and New Features

Version R2003.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
VIP-Executive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
New Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Modified Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
VDB Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
DeskTop-VIP User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
VIP Job Submittal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
SimResults / SimResults+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
VIP 2003.4 Unix/Linux Release Notes Page 3

Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
VIP Convert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
VIP Data Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
VDS-CORE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
VDS-EXEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Known Issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Grid Calculator (GridCalc) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Known Issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Region Calculator (RegCalc) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
E2V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
GridGenr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Installation
VIP Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
LAM License Manager

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Version Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Understanding the License Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Using the License System with Third-Party Software . . . . . . . . . . . . . . . . . . . . . 30
LAM 2003.0 Guide -- Linux and Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
LAM System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Obtaining a Server License File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Installing LAM Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Controlling the License Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Starting and Stopping the License Server . . . . . . . . . . . . . . . . . . . . . . . . 39
Setting the Environment Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Defining License Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
LAM Technical Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
If Applications Cannot Find License File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Overriding LM_LICENSE_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Restricting the Use of FLEXlm Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Setting the Environment

Setting the Users Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Without OpenWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Other Important Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Appendix A: Parallel Computing

Getting Started with PARALLEL-VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Include File Configuration Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Which Systems Will Parallel-VIP Run On? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Where Should You Run From? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Running on IBM SP Workstations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Running on Shared Memory Silicon Graphics, Solaris, and Linux
Workstations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
File System Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
.rhosts File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Remote Shell Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Testing for Valid rsh Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Other Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Appendix B: NFS Mounting Requirements for Parallel or Remote Submission

Manual Mounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Automount Mounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Environment Variables and Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Appendix C: Setup Instructions to Submit Jobs via Remote Shell

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Assumptions: About the Users Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Key Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Key Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Job Submission Panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Appendix E: SP2 POE Checkout Guidelines
Appendix F: Modifying a Samba Server to Work with VIP Applications

Using Samba shares in Remote Windows VIP Submissions or Parallel Windows VIP
Submissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Using Samba Versions 2.2.2 and Higher with VIP applications. . . . . . . . . . . . . . . . . . . 74
Example smb.conf File Used During Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75


Introduction
These Release Notes provide the necessary information to correctly install
DESKTOP-VIP Release 2003.4 on Windows 2000 machines. They also contain
operating system support levels and required third party software, as well as
instructions for setting up parallel configurations, network dependencies and
tested hardware configurations. Instructions for uninstalling older versions of
DESKTOP-VIP and related third party software are also included in these
Release Notes.
Whats New
DESKTOP-VIP R2003.4 provides a graphical user interface that is certified on
Windows 2000 Service Pack 1 and 2. It has also been tested on Windows XP
Professional, with no problems detected. VIP simulators are certified on
Windows 2000 SP1 and 2, as well as Solaris 8, IRIX 6.5.11m, and AIX 4.3.3,
and Linux Red Hat 7.2. VIP simulators have also been tested on Windows XP
Professional with no problems detected.
This release provides a wide range of enhancements, including the following

major changes to Windows-based user interface applications:
Desktop. The new JAVA-based Desktop has a Windows look-and-feel, with

features like docking/floating toolbars and mouse-over tooltips. Study/
Case management and network access from the Desktop has been
improved.
Job Submittal. The new JAVA-based Job Submittal application with

emphasis placed on ease-of-use, job queueing, remote job submittal,
and input/output/include file management.
SimResults and SimResults+. The SimResults plotting application takes
advantage of Windows-based features such as drag-and-drop to let you more
efficiently use those plotting capabilities that were available in PlotView.
SimResults+ (license required) also lets you create RTF plots, allows for
batch plotting, and provides a seamless interchange between Eclipse and VIP
data and .grf templates.
Enhancements to VIP Data Studio. This efficient, wizard-driven application

has been expanded to let you create VIP-CORE as well as VIP-EXEC data
files.
VIP Convert. This powerful conversion application now lets you export and
import Rescue geocellular model data.
Desktop-VIP 2003.4 Release Notes Page 7 Introduction

RegCalc (Region Calculator). This new application lets you quickly obtain
pressure, saturation, and fluids in place at any timestep for both your
IREGIONS and any arbitrary I,J,K area (not defined as an IREGION).
DESKTOP-VIP R2003.4 provides numerous enhanced simulation capabilities,

including:
Enhanced Surface Pipeline Network, including optimization of well and

gaslift gas rates, and multiple output streams from nodes.
A basic implementation of injection networks in addition to production

networks.
Version independent restarts from R2003.4 forward. (A utility is provided to

convert from R2003.0 to R2003.4)
Option for control of gas re-solution rate. (DRSDT)
Support for multiple water PVT regions, including optional property

variations with salinity.
Optimization of gaslift gas utilization at all targeting levels.
Threshold pressure option for fault flow.
Simultaneous bottomhole and tubinghead pressure constraints.
All new and enhanced functionality is described in the Enhancements and New
Features section of this document.
VIP Unix/Linux Users

Desktop-VIP graphical user interface applications are only available on
Windows 2000. Except as noted below for Geolink and 3DView, only Unix and
Linux simulators are provided and can be found on separate CDs. You can use
the Desktop-VIP on Windows 2000 to submit remote simulation jobs (serial or
parallel) to Unix/Linux machines. GeoLink certified on Solaris and IRIX
platforms is part of the Stratamodel R2003.0 offering. A certified version of
3DView for Solaris and IRIX is part of the OpenVision R2003.0 offering. A
tested version of 3DView for Linux is part of the OpenVision R2003.3 offering.
Desktop-VIP 2003.4 Release Notes Page 8 Introduction

System Requirements
The minimum hardware requirements are a UNIX or Linux workstation with 200
MB of free disk space to store the VIP simulation software, as well as a CD drive
either local or mounted across the network for unloading the software from the
installation CD.
The amount of memory and swap space necessary to run VIP is dependent on the
size of the model. However it is recommended that you have at least the following
minimum configuration. This allows a model with approximately 100,000 grid
blocks to be run.
Minimum RAM: 256 Megabytes
Minimum Swap: 512 Megabytes
Minimum tmp: 512 Megabytes
Minimum Disk: 4 GB system/ 9GB user space
VIP 2003.4 Unix/Linux Release Notes Page 9 System Requirements

Sun Solaris Operating Systems

Serial and parallel VIP executables are available for Solaris operating systems.
Tested Environment
VIP R2003.4 was tested on Solaris 8 (SunOS Release distributed October 10, 2000).
Parallel Requirements
Parallel-VIP was tested on Solaris 8 running on shared memory Solaris
workstations. For additional information on parallel computing requirements,
refer to Appendix A.
Additional Software Requirements
The Message Passing Interface (MPI) Version 1.1.0 is required and is supplied on
the VIP installation media.
Additional Hardware Requirements
Shared memory Solaris workstation with two or more CPUs in a single machine.
It is recommended that sufficient disk space is added to provide adequate swap,
tmp, and storage space. The executables for Paralled-VIP to run in a distributed
cluster across two or more separate Solaris machines are not provided.

IBM AIX Operating Systems

Serial and Parallel VIP executables are available on AIX operating systems.
Tested Environment
VIP R2003.4 was tested on AIX 4.3.3.
Parallel Requirements
SP platforms running IBMs Parallel Operating Environment. A distributed
version, running MPI, is not available. For additional information on parallel
computing requirements refer to Appendix A.
Additional Software Requirements
Parallel Operating Environment (POE) 2.4
Parallel System Support Program (PSSP) 3.1.1
Additional Hardware Requirements
It is recommended that sufficient disk is added on each node to minimally provide

swap space and tmp space that is two times larger than real memory. Other disks
should be added locally to the SP to store user files.

SGI IRIX Operating Systems

Serial and Parallel VIP executables are available on IRIX operating systems.
Tested Environment
VIP R2003.4 was tested under IRIX 6.5.11m.
Unique Parallel Requirements

Parallel-VIP runs on a 64-bit SGI Shared Memory workstation (8000 or greater;
i.e. Power Challenge, Origin, Octane) that has two or more CPUs. For additional
information on parallel computing requirements refer to Appendix A.
Software Requirements
Hardware Requirements
Shared memory SGI workstation with two or more CPUs in a single machine. It is
recommended that sufficient disk is added to provide adequate swap, tmp, and
storage space. The executables for Paralled-VIP to run in a distributed cluster
across two or more separate Solaris machines are not provided.

Linux Operating System

Serial and parallel VIP executables are available on Linux operating systems.
Tested Environment
VIP R2003.4 was tested under Linux Red Hat Version 7.2.
Unique Parallel Requirements

Parallel-VIP runs on a Linux Distributed Memory workstation that has two or
more CPUs. For additional information on parallel computing requirements refer
to Appendix A.
Software Requirements
Distributed memory Linux workstation with two or more CPUs in a single

machine. It is recommended that sufficient disk is added to provide adequate
swap, tmp, and storage space. Parallel-VIP will run in a distributed cluster across
two or more distinctively separate Linux machines.


Enhancements and New Features
Version R2003.4
This release of DESKTOP-VIP provides the following new and modified
features for both the Unix/Linux and Windows versions.
VIP-Executive
The following notes describe features which were added or modified in VIP-
EXECUTIVE. Some of these features offer new capabilities and others offer
better efficiency. Features that are pertinent only to VIP-CORE or VIP-EXEC
are listed separately.
General
1. Change bars specific to version R2003.4 have been retained in the CORE and
EXEC user manuals to aid the user in quickly locating new/modified
information.
2. Note: VDB and map files have always been required to have ROOT as the
root grid name. If the root grid is renamed in VIP-CORE (LGR ROOTGRID
option), all input data is required to use this name and output files will reflect
this name, but applications such as 3DView that read from the VDB will show
the root grid as ROOT.
New Features
1. Version-independent restart files: The restart files have been restructured

to enable the flexibility of version-independent restart files. For all future
versions, VIP-EXEC will be able to restart from any prior restart files,
eliminating any requirement to rerun the entire study when moving to a new
version. A utility program is provided to convert current R2003.x restart files
to the new structure, enabling R2003.4 to restart from converted R2003.x
restart files.
Converting Restart Files:
Modify script for VIPHOME. Using your text editor (such as Notepad or
vi), open the script file (rstconv.bat on Windows or rstconv.ksh on Unix/
Linux) located in your VIP directory path /vip/dtvip/cvrst. On the following
line, edit the file to point to your VIPHOME location.
set VIPHOME=net/machinename/vip
Save and close the file.
Desktop-VIP 2003.4 Release Notes Page 15 Enhancements and New Features

Run the conversion. In the case file directory, type the following at the
command line prompt:
rstconv <oldrestartfilename> <newrestartfilename>
You need only specify the base restart file name (filenamei.rst) for a CORE
run and base output restart file name (filenamer.rst) for an EXEC run. The
script will then read and convert multiple restart files: filenamei.rst,
filenamei.rst0, filenamei.rst1, ... , where a numbered file is expected for each
grid.
2. Control of gas re-solution rate: In conjunction with the new extended form
of the black-oil PVT tables (BOETAB, etc.), a new DRSDT variable has been
added which enables the user to limit the rate of increase of the solution gas-
oil ratio, Rs.
3. Multiple water properties regions: Enables the user to specify different

water PVT regions, with different properties in each region, in a manner
analogous to the specification of different hydrocarbon PVT regions.
4. Water properties variation with salinity: Allows the user to specify the
variation in water properties as a function of salinity for any water PVT
region, enabling more precise modelling of fresh water injection. The salinity
of the injected water can be specified for each water injection well.
VIP-CORE
1. Aquifer connections to LGRs: Enables aquifers to be connected to any

gridblock within any grid, rather than being limited to the base grid, only.
2. Limits removed for the reference depth for the initial pressure in an
equilibrium region which has an active gas-oil contact: The reference
depth for the initial pressure in an equilibrium region involving an active gas
cap is now allowed to be outside of the oil leg, since the phase pressure
profiles will be based on the saturation pressure at the GOC.
3. XREG values can be read for each gridblock. XREG data can also
be read using a value for each gridblock in the window. Previously,
only one value could be applied to the whole window.
Known Issue:
1. The CORE keyword VDB filename.vdb only works for local runs.
VIP-EXEC
1. Enhancements to the production Surface Pipeline Network (SPN) option:

A number of enhancements have been made to the production SPN. These
include the following:

a. Optional well rate and gaslift gas rate optimization.
b. Pseudo well option for satellite field modelling.
c. Allow multiple output streams from nodes.
d. Simplified heat-transfer analysis extended from wells to nodes.
2. Basic implementation of an SPN for injection wells: Enables a separate

network to be defined and used for the injection system.
3. Optimization of gaslift gas utilization at all targeting levels: Enables the

user to solve for the minimum gaslift gas required to make the production
targets at any level, outside of SPN.
4. IMPWEL now available with OPTMBL and Crossflow: The implicit well
option with the IMPES formulation can now be used in conjunction with both
OPTMBL and the wellbore crossflow options.
5. Threshold pressure option for fault flow: Enables the flow across a
specified fault to be blocked until the pressure potential exceeds the specified
threshold. When exceeded, the potential is reduced by the value of the
threshold, and flow is allowed based on the adjusted potential.
Modified Features
VIP-CORE
1. Automatically connect analytical aquifers to only gridblocks below the

water-oil contact: In previous versions, connections were made to all
gridblocks specified, irrespective of whether they were above or below the
contact.
Fixed Problems
1. MULT PLUS data now propagates correctly to children LGRs.
2. MULTFL now works correctly with LGR or DECOMPOSE and no longer

results in convergence failures in EXEC.
3. Some pinchouts across LGRs with OMITs could be missed.
4. Multi level LGR or DECOMPOSE grids no longer have corrupted map files
that cannot be loaded into 3DView.

VIP-EXEC
1. Support for both previous algorithm and iterative damping for

OPTMBL: In the R2003.0 release, iterative damping was introduced with no
ability to request the old algorithm. Now the old algorithm is the default, and
iterative damping may be requested by specifying DAMP on the OPTMBL
card.
2. Support simultaneous THP and BHP constraints for wells: The simulator
will now allow and utilize both THP and BHP constraints for a well
simultaneously, honoring the more restrictive of the two. Previous versions
would use only the last one entered, negating either of the two previously
entered.
3. Make-up gas rate and composition of injected gas: The actual required
rate of make-up gas to satisfy the gas reinjection requirement is now correctly
calculated and reported, as well as the correct injection gas composition
involving the produced gas plus required make-up gas.
4. Default for the automatic solver cutback changed to OFF: In the R2003.0
release, a new feature was introduced within the solver to attempt to
determine either very slow convergence or divergence, and terminate the
solution effort, with the idea being to save the excess CPU time of continuing
to maximum iterations and then cutting the timestep. After finding several
models in which this hurt the overall performance, the default is changed to
OFF, and the user must explicitly turn it on if deemed necessary.
5. Enhanced convergence and constraints on the welbore gradient methods:

Enhanced convergence criteria and tighter constraints within the iterative
wellbore gradient calculations now yield much better performance for a few
special cases wherein the previous versions produced premature shut in of
some wells.
6. Numerous additions to the various output files: Significant additions have

been made to the output capabilities of the spreadsheet, plot, and map files.
Fixed Problem
1. Excessive memory utilization in the solver for inactive gridblocks.
VDB Database
The following notes describe features which were added or modified in the VDB
database.
1. New structure implemented: A new VDB directory structure has been

implemented to replace the single-file VDB model. This new structure:
Allows for faster data access

Allows more simulation runs for a single study without hitting the 2GB
file size limit
Eliminates the need for VDB defragmentation
The new VDB structure is described in detail in the Starting and Using
Desktop-VIP chapter of the Getting Started manual.
Convert old VDBs by running this command at the command-line prompt

from within the directory containing the old VDB:
vdbconverter <old_vdb_name> <new_vdb_name>
All DeskTop-VIP applications can easily handle both old and new style VDB
files. The command-line executable will also convert from the new to the old
format.
2. VDB control file provided: An XML control file has been provided in the
top-level directory of the new VDB allows users to easily see the list of cases
and parent-child relationships among them
3. Simultaneous VDB access: Multiple VIP simulation jobs can now access the
VDB simultaneously.
DeskTop-VIP User Interface

The following notes describe features which were added or modified in the
Desktop.
1. GUI redesign and new features: The DeskTop user interface has been re-
written in Java, eliminating all dependencies on Tk/Tcl. It now has a
Windows look-and-feel, with features including docking/floating toolbars,
mouse-over tooltips, etc.
2. Improved study/case management: The new DeskTop user interface allows

the user to load multiple VIP studies onto the Desktop and easily switch back
and forth between active studies/cases. The VDB study/case hierarchy is now
visible to the user on the Desktop, and studies/cases can be added, deleted, or
modified from the Desktop. Data types contained in the study/case are easily
visible to the user at all times.
3. Study/case comments can be added: The user now has the ability to add
study/case comments which can easily be viewed.
4. Persistence of user preferences: Changes/preferences set by the user are

persisted from session to session.
5. Improved network access. The network can be now accessed from the file
selection dialog box.

VIP Job Submittal

The following notes describe features which were added or modified in VIP Job
Submittal.
1. GUI redesign and new features: The VIP Job Submittal interface has been
totally redesigned, with the emphasis placed on ease-of-use, job queueing,
and remote job submittal.
2. Input, output, and include files shown:. The Job submittal panel now
displays all input files, output files, and include files associated with a given
VIP job.
3. Improved simulation messages: The feedback to the user while jobs are
executing has been improved.
4. More control over the run: Jobs can now be run as a background process
and multiple jobs can run simultaneously. The user can now choose which
simulator version to use for each run.
5. Real-time plotting: A user-configurable feature has been added for real-

time plotting of simulation results while a job is running.
6. Local or remote queueing: Jobs can be queued to run either locally or

remotely.
7. Batch plotting for automatically-generated plots: Batch plotting has been

improved for automatically generating plots of simulation results. Output can
be sent to the default printer, to Microsoft Word document, Excel document,
Powerpoint document, or HTML files.
Known Issues
1. For remote runs using this release version, the directory that is one level
above the Study directory is reserved for remote copy procedures. Therefore,
no primary data files ( i.dat and r.dat ) or restart files ( i.rst and r.rst ) may exist
in the directory immedi-ately above the Study Directory. If they do, they will
be copied to the directory immediately above the remote working directory.
The simulator will not be able to find them during the remote run and the
simulation will fail
2. When specifying the location of include files, it is recommended that the user
always specify fully qualified paths. Relative paths will only work one level
higher (../) and one level lower (./); however there are situations where they
will not work at all.
3. The VDB option in CORE is not supported for remote jobs submitted from
Desktop-VIP, if the *.vdb file is to be automatically copied to the remote
machine. However, if the user manually copies the *.vdb file to the working
directory on the remote machine, the VDB option will function properly.

SimResults / SimResults+
A new Windows-based plotting package has been added to Desktop-VIP to
replace PlotView. (PlotView has been retained on the Desktop for this release.)
1. SimResults drag-and-drop GUI: SimResults provides all the functionality

that was available in plotview, within a drag-and-drop user interface for
creating X/Y plots and 2D maps.
2. SimResults+ enhanced functionality: SimResults+ provides additional

functionality, including:
Full batch plotting support via GRF scripting language
RFT plotting
User definable derived quantities
2D map display for VIP map data
Known Issues
1. If you have a new Windows 2000 machine, Microsoft Office must be installed
in order to run SimResults.
2. If you are a new user or have a new Windows 2000 machine, then the
message prompting for Office 2000 SR-1 disk is produced if SimResults (or
any application that has been compiled using Visual Studio) is run.
Work-around: This issue can be solved by running any office application

once, e.g. start Word then close it down.
VIP Convert
The following notes describe features which were added or modified in the VIP
Convert conversion utility.
1. Additional export capability: VIP Map, VIP CORE, Landmark Active

Field Surveillance (AFS) and Rescue files can now be exported from the
VDB study/case.
2. Additional import capability: RESCUE models can now be imported into a

VDB file.
3. VDB viewing from the VIP Convert application: A new VDB View
panel has been added to allow the numerical data contained in a VDB study/
case to be viewed.
4. Improved status reporting. Status reporting to the user while VIP Convert is
processing files has been improved.

VIP Data Studio

The following notes describe features which were added or modified in VIP-
Data Studio. Features that are pertinent only to VDS-CORE or VDS-EXEC are
listed separately.
1. External data can now be imported or entered: Data can be be parsed,

and unrecognized parsed data is now saved as an include file for import.
2. Summary (error) page provided: A summary page of the model is now

displayed to the user before the data set is generated. The summary provides
basic error checking (missing data, obvious errors).
3. Color-coded icons: Icons have now been added to each data type in the
options tree. A green icon indicates that all required data has been entered. A
yellow icon indicates that no data has been entered but none is required. A
red icon indicates that mandatory data is missing.
VDS-CORE
A user interface has been added to create basic CORE initialization files. It lets
the user parse an existing initialization file and import tables from existing
datasets. It also provides a creation wizard to quickly generate the basic
requirements for an initialization file from scratch.
Data Studio CORE supports the following data:

Basic utility data
Local grid refinement
Limited support for advanced utility features (Dual, Therm, etc.)
Equilibrium tables
Rock tables (relative permeability and compaction)
PVT tables for black-oil, water-oil, gas-water, EOS
Basic correlations to generate relative permeability tables and black-oil/
water-oil, gas-water PVT
EOS separators
Grid data through view for simple grid arrays or as include file
Grid Array functions
Grid Modifiers
Aquifers
VDS-EXEC
New production data options available. The Production Data panel now
supports:
Active Field Surveillance (AFS) file import

User-defined conversion factors through the import wizard

Class header definition for export to OBS format through the import wiz-
ard
Appending of imported pressure data after importing rates/volumes,
allowing different time frequency for pressure measurements
Generation of types and rate constraints from raw production data (no
averaging required)
New output options available: The Output panel now supports:
RFT output (well selection)

SSSUM option
Compositional MAPX/Y/Z and OUTX/Y/Z options
New well perforations options available: The Well Perforations panel now
provides:
An import wizard to generate VIP PERF cards from a simulation grid

within a VDB and some basic well data
Ability to filter displayed perfs by well, date, and/or well name
New well constraints options available: The user can now view all con-
straints for a well. The Well Constraints panel now supports the following
constraints:
Hydraulic table assignment

Gas Producer THP table assignment
Tubing length
Tubing diameter friction factor
Crossflow model activation
Minimum rate scale-back for targeting
New well hierarchy option available: Basic injection and production tar-
geting plus hierarchy ontime factors is now supported.
Known Issue
1. When launching 3DView from the VIP Data Studio perforation wizard, the
3DView main window sometimes locks due to an Exceed problem.
Workaround: close the DOS command window that comes up when
launching 3DView from the perforation wizard. (This will also close the
current 3DView without killing Exceed). Then relaunch 3DView from the
perforation wizard.

Grid Calculator (GridCalc)

The following notes describe features which were added or modified the
GridCalc utility.
1. GUI redesign: The user interface has been redesigned with a Windows
look-and-feel.
2. New trigonometric functions added: Sine, cosine, tangent, and square-root

functions have been added to the calculator pad.
3. Summation capabilities added: The user can now perform summations by

time or by layer.
4. Temporary variables can be created: The user can now create temporary
variables as building blocks for more complex permanent variables. The
temporary variables are deleted at the end of the session.
5. Improved error-checking and messages: The application now performs

more complete error-checking and provides better error messages to the user.
Known Issue
1. In GridCalc expressions, the program only recognizes VDB and Case names
that start with an alpha character. For example "name2" is a recognized VDB
or Case name in an expression, but "2name" is not. Workaround: if you
want to use a VDB or Case name that does not begin with an alpha character
in an expression, select it as the active Project and Case. Then create the
expression without specifying a Project or Case. When not specified, the
program assumes the current Project and Case by default.
Region Calculator (RegCalc)

The following notes describe features which were added or modified the
RegCalc utility, which replaces MapCalc.
1. GUI redesign: The user interface has been redesigned with a Windows
look-and-feel.
2. New features to aid in transfer of data to spreadsheet: A new Copy

feature lets the user easily copy data to the Clipboard to paste into a
spreadsheet application. A new Export feature lets the user quickly create a
tab-delimited file for import into a spreadsheet application.
3. Improved report options: Multiple timesteps can now be included in a single

report. New Print Preview and Column Layout control has been added to give
the user more control over the report hardcopy.
4. Improved error-checking and messages: The application now performs

more complete error-checking and provides better error messages to the user.

E2V
The following notes describe features which were added or modified the E2V
utility.
1. Extended black oil table data converted: Extended black oil table (e.g.
BOETAB) data is now converted to VIP format.
2. Multiplication data now converted: Data for multiplying named faults

(MULTFL) and multiplying transmissibilities between reservoir regions
(MULTIR) is now converted into VIP format.
3. Observed file can now be created: An option has been added to create an
observed data file (*.obs) during the conversion process.
4. Eclipse BHP reference depth can be converted: The default BHP reference
depth (depth to top perforation) from Eclipse has been added as an option.
5. Well scheduling data can now be created: Well scheduling data can now be
created in a compressed format based upon user selection.
6. Conversion improvements have been made: A variety of bug fixes have

been added to make the conversions more complete and reliable.
Known Issues
1. For Eclipse data sets containing non-monotonic PVT data, the converted data
set may report errors when run in VIP. In some cases, E2V slightly modifies
the data to cause monotonic behavior, but in other cases the data is not
adjusted.
2. The conversion of Eclipse gas and oil viscosity in the PVT tables cannot be
guaranteed. You should manually check and verify this data.
3. The conversion of MULTZ data in Eclipse to TMZ data in VIP may have
errors.
4. When Eclipse data has UTM coordinates, you must choose the right-handed
option in order to ensure the correct results. The left-handed option (default)
is not guaranteed to work correctly.
5. For VIP, the matrix and fracture systems must have the same equilibration
region specified by the IEQUIL array; there is no IEQUILF array. Eclipse
allows the matrix and fracture systems to have different equilibration region
specification for each grid block.
6. GASWATER and WATEROIL options are not allowed in VIP-DUAL.

GridGenr
The GridGenr model size limitations were retested with the following results:
1. Grid points per zone. The maximum number of grid points per zone
increased from 60,000 to 300,000.
2. Mesh size. The maximum size of a mesh increased from 500,000 to

1,000,000.

Installation
The VIP simulator installation CDs are written in standard Landmark Graphics
CD Release Manager (CDINSTALL) format. They are used to install VIP on all
supported UNIX and Linux platforms.
This install media contains the shell script setup and the necessary tools to
extract the application from CD and transcribe the application to disk.
For UNIX, the CDINSTALL packs the application in such a manner that the
application itself cannot be run from CD. It must first be transcribed to disk, then
invoked from disk. This is accomplished by running the Release Manager. For
Linux, an auto-mount is provided. Once the CD is inserted, you need only cd to
the directory /mnt/cdrom/install.
The CD Release Manager program provides a consistent GUI-based interface for

installing VIP. After you specify the programs to be installed and the directories in
which to install them, the program provides a graphical status display of the
installations progress. Do not use the upgrade option as it is not functional.
Please refer to the next chapter for procedures on mounting and managing the
license server.
VIP Installation
After inserting the VIP CD into your local CD drive, login in as root and change
directories to your CD drive. Change directories to the install directory and type
the following command:
./setup
The following message appears:
|----------------------------------------------------|
| Landmark Graphics Corporation |
| Release Manager |
|----------------------------------------------------|
Log files are written to CDINSTALL_LOG

CDINSTALL_LOG is set to : /tmp
Is this correct [y]?
OWHOME must be set: A full path is required

Please enter path:
If you have OpenWorks, enter the full pathname to your OpenWorks 2003 home
directory. This pathname is used to determine where to locate the VIP installation.
For example, if your OpenWorks area is located under /usr/apps, the full
pathname should be entered as /usr/apps/OpenWorks.
VIP 2003.4 Unix/Linux Release Notes Page 27 Installation

If the environment variable OWHOME is defined before starting the CD install

procedure, then the question above never appears and the pre-defined OWHOME
directory path is used as the installation location. VIP will be installed in a
directory relative to the installation location. For example, if the installation
location is /usr/apps/OpenWorks, VIP is typically installed in /usr/apps/
OpenWorks/vip.
If you do not have OpenWorks, similar rules apply, except that you supply a full
directory pathname the location on your file system where you want VIP
installed. For example, if the pathname you supply is /usr/apps, VIP is installed
in /usr/apps/vip.
VIP 2003.4 Unix/Linux Release Notes Page 28 Installation

LAM License Manager
Introduction
Landmarks license system (LAM) is based on Globetrotter Softwares
FLEXlm licensing server package.
This document describes the procedures for installing, configuring, and

managing the license system to control the usage of Landmark
applications, including the following topics:
Version Compatibility described below
Using the License System with Third-Party Software on page 30
LAM 2003.0 Guide -- Linux and Unix on page 31
Version Compatibility
Each Release of a Landmark application has a version of FLEXlm with
which it is certified.
Landmark Release FLEXlm Version Operating System
2003.0, 2003.4 7.2e Windows, Solaris, IRIX, AIX
2003.0.1 7.2e Solarix, IRIX
2003.1 7.2e Windows
2003.3, 2003.4 7.2g Linux
Release 2003.0 and later use new security enhancements incorporated

into FLEXlm server and license files for version 7.2e and later. As a
result, Release 2003.4 applications will not work with earlier FLEXlm
versions.
The LAM 2003 Server software must be installed and new license files
must be obtained prior to attempting to run any Release 2003.4
applications. The detailed procedures to perform these tasks are
contained in the platform-specific chapters of this guide.
VIP 2003.4 Unix/Linux Release Notes Page 29 LAM License Manager

Understanding the License Process

The license process is described in detail in the LAM Guide that was
included in the R2003.0 release. Refer to the Guide for a detailed
explanation of licensing.
Using the License System with Third-Party Software

Because Landmarks License System uses FLEXlm from Globetrotter,
administrators must be careful when installing other third-party
software that also uses FLEXlm (Suns compilers, Charisma, etc.).
When your environment contains Landmark applications (either VIP

only or in combination with other products such as OpenWorks) and
other third-party software, there are two ways to manage the license
system:
The first (and easiest) way produces separate license systems.

Landmark applications reference one license system while third-
party software references the other license system.
The second (more complicated) way produces a single license

system that is used by both Landmark applications and the third-
party software.
Procedures for each type of license set-up are described in the LAM
Guide. The Guide assumes that your license file is in the OpenWorks
environment. When reading these procedures, substitute your VIP path
(or wherever FLEXlm is installed) for the OpenWorks path.

LAM 2003.0 Guide -- Linux and Unix
Introduction
This chapter describes LAM on Linux and UNIX platforms and
contains the following major topics:
Obtaining a Server License File on page 31
Installing LAM Server on page 34
Controlling the License Server on page 38
LAM Technical Notes on page 41
LAM System Requirements
Operating System
AIX 4.3.3, IRIX 6.5.11m, Red Hat Linux 7.2, Solaris 2.8.
The memory, disk storage, and bandwidth needed for the License
Server is minimal when compared with the capability of modern
workstations, servers, and networks. For instance, as a base the
FLEXlm daemon, lmgrd, uses about 160 KB of memory, and the
Landmark daemon, licsrv, uses about 180 KB; however, with a large
license file and with a large number of users, both daemons may use
about six megabytes of memory.
The storage requirements remain relatively static, around eight or nine

megabytes.
Obtaining a Server License File

Before you begin, check LAM Technical Notes on page 41.
A license file must be obtained from Landmark Graphics Corporation

before you can start the license server and run the VIP applications.
1. Log on to the server that will run LAM Release 2003.0.
2. Enter one of the following commands in a terminal window to

display the host ID of the system where the LAM server executes.

The number can be a hexadecimal number or a decimal number. If

the number is decimal, a numeral or pound sign ( # ) must
immediately precede the decimal number.
AIX
FLEXlm uses the machine ID as the host ID. To retrieve the

machine name, use the uname command. For example:
uname -m
The command returns a twelve digit number. For instance:
000276513100
The first two and last two digits are always zeros. Strip away the
first two and last two digits, and used the middle eight digits as the
host ID. For example:
02765131
Machine ID May Change With Operating System Changes
The identifier returned by uname may change after the software levels
of the AIX operating system are changed. This change may affect the
validity of your Landmark license.
IRIX
anw% /etc/sysinfo -s
The sysinfo command display information similar to the

following:
1762857767
In the example above, the number that sysinfo produces is a

decimal number, 1762857767 . For the LAM server, the host ID
must be provided in the following form: #1762857767 . To convert
it to a hexadecimal number, use the following commands:
echo DecimalNumber 16o p | dc

HexadecimalNumber

For example, using the number from sysinfo provided above, the
command sequence would provide the following:
anw% echo 1762857767 16o p | dc

69131327
Linux
In Linux, the ID of an Ethernet interface (or adapter) is used as the

host ID of the system. Use the ifconfig command to find the ID of
the interface. For example:
/sbin/ifconfig Device
where Device is the name of the interface driver (such as eth for an
Ethernet interface) with its device number. For example, the first
Ethernet adapter in the computer would be eth0 .
The command will display the ID of the Ethernet interface as the

hardware class address (HWaddr). This address is composed of
twelve hexadecimal digits separated into pairs by colons. For
example:
01:32:09:F6:A5:F5
For the LAM server, the host ID is the number without the colons.
For example, given the address above, the following would be the
ID of the Ethernet interface:
013209F6A5F5
Solaris
highpoint% sysdef -h
The sysdef command display information similar to the following:
*
* Hostid
*
7233926c
In the example above, the number that sysdef produces is a

hexadecimal number, 7233926c .
3. Write the Host Name here: _________________________

To retrieve the host name from the system, enter the following in a
terminal window:
uname -n
4. Request the license file from the following address:
http://www.lgc.com/support/licensing
Provide Landmark Licensing with the host ID and the host name
as well as the type of license, number of users for the license,
machine manufacturer and model, and operating system name and
version.
5. Copy the license file to a folder on the machine where the license
server runs and is accessible by the license server.
Typically, the pathname for the license file is $OWHOME/lam/

license.dat . If you give the name any other pathname, you must
include the path name as a parameter in the command that starts
the license server. For example:
$OWHOME/lam/bin/startlmgrd -c /export/home/license/license.dat
Or, you must assign the LM_LICENSE_FILE environment

variable to the pathname. For example:
setenv LM_LICENSE_FILE $OWHOME/lam/license.dat
Installing LAM Server

The steps to install LAM server are contained in this section.
The following procedure should also be used if you must reinstall the
License Manager files.
Use the following steps to install LAM server.
1. Log on as root.
2. If you are logged in remotely to the system where you are

installing LAM, do the following:
On the remote system, set the DISPLAY environment variable:
setenv DISPLAY LocalMachineName:0.ScreenNumber

On the local system, allow the remote system access to the local
system:
xhost + RemoteMachineName
3. Run the Setup program. For example, you may enter the
following:
/cdrom/CDInstall/install/setup
The Release Manager for R2003 begins running in the terminal

window and will prompt for the location of log files.
4. Enter y to accept the default, /tmp .
Or, enter n , and enter another path for the log files.
5. If the OWHOME environment variable has not been set, you will
be prompted to enter its path. The path must be a complete
pathname, such as:
/d01/programs/OpenWorks
Release Manager displays the location of the OpenWorks home

directory (contained in OWHOME) and asks you to confirm
whether it is correct.
6. Enter y to accept the setting of OWHOME.
Or, if the location is not correct, enter n , and enter another

location for the OpenWorks home directory.

7. If the location does not exist, the Release Manager will ask you to
allow it to create the directory or subdirectories that do not exist.
Enter n to re-enter the OpenWorks home path or to stop the

installation process.
Or, enter y to allow the Release Manager to create directories. The

Release Manager - Product Selection dialog opens, and the
Release Manager Release Notes dialog opens on top of the
selection dialog. The Release Notes contain a list of the features of
OpenWorks 2003 and a list of the platforms on which it runs.
8. Click OK to close the dialog.

The Release Manager - Product Selection dialog lists the

Landmark products on the CD.
9. Select Install in the option menu for LAM.
10. Verify the installation location. If you need to change the

installation location, click the Browse () button associated with
the product and navigate to the correct location.
11. Select Linux for the Linux operating system, SUNSV for the
Solaris operating system, IRIX64 for the IRIX operating system,
or AIX for IBMs AIX operating system, in the Target OS option
menu.

12. Click Start. The Product Installation Status dialog opens with the
Installation Status Window.
The Release Manager will display a series of status messages in

this dialog as it extracts the product.
After LAM installs, the Product Installation Status dialog indicates

its installation.
Next, the Product License Information dialog opens to remind you

to contact Landmark Graphics Corporation about the license for
your software.
13. Click OK in the Product License Information dialog.
14. Click OK in the Product Installation Status dialog.
15. Click Close in the Installation Status Window.
The Release Manager - Product Selection dialog redisplays,

indicating that LAM has successfully installed.
16. Click Exit in the Release Manager - Product Selection dialog.
17. When prompted to confirming exiting CD Installer, click Yes.
A Warning dialog displays, asking you to determine whether to

keep the log files or not.
18. Click OK to delete the log files, or click Cancel to save the log
files.
CD Installer stops running.
Controlling the License Server

After acquiring a license file for the software you have purchased, but
before you use the software, you must start the license server. You can
start the license server manually, or you can configure the license
server to start when the system boots.

Starting and Stopping the License Server
The system startup file on the license server is modified at installation

time to start up the license daemon. Use the following steps to start and
stop the License Server.
1. To start the server manually, log in as root to the workstation

containing the license server, change to the LAM bin directory
under OpenWorks, and enter the startup command. For example:
telnet nova
login: root
setenv OWHOME /pa/OpenWorks (C Shell), or
OWHOME=/pa/OpenWorks;export OWHOME (Bourne or Korn Shell)
cd /pa/OpenWorks/lam/bin
./startlmgrd
2. To stop the License Server, use the same procedure as indicated in

the previous step, but substitute the following command:
./stoplmgrd
Setting the Environment Variable
The LM_LICENSE_FILE environment variable is an environment

variable provided by the FLEXlm license server package. It performs
the following functions:
Allows users to designate a license.dat file that the application will

use to attempt to check out a license
Allows users to specify a list of license.dat files that the application

has available to use in checking out licenses.
LM_LICENSE_FILE has a syntax exactly like that of PATH. For

example, C shell users would use the following commands:
setenv LM_LICENSE_FILE $OWHOME/license1.dat

setenv LM_LICENSE_FILE $OWHOME/license1.dat:$OWHOME/license2.dat
Defining License Groups
A License Group is one or more workstations using a single License

System, including a license.dat file and one or more License Servers
(represented by SERVER lines in the license.dat file).

Large sites may want to partition their workstations into distinct

groups. Each workstation group would have a License System
including:
a license.dat file
one or more workstations designated as License Servers.
The user defines LM_LICENSE_FILE to point to the license.dat file

that is to be used by applications running in the group.
Group License Sharing
Groups may share licenses with other groups through the use of the
LM_LICENSE_FILE environment variable:
Each group has a copy of each license.dat file from the other groups
(hopefully all named appropriately).
The user environment contains the LM_LICENSE_FILE defining

the exact location of each of the above license.dat files. In addition,
LM_LICENSE_FILE defines an order that the application will
follow when trying to check out a license from one of the groups.
Be aware of licenses common to one or more of the above license.dat

files and the problem associated with searching LM_LICENSE_FILE.
An example of a LM_LICENSE_FILE variable setting for a group is
shown below:
setenv LM_LICENSE_FILE /etc/license_g1.dat:/etc/license_g2.dat
NOTE: Rollover in LAM version 2003.0 does not work properly. If a user runs out
of licenses in the license_gl,.dat file, LAM will not automatically rollover to
license_g2.dat.

LAM Technical Notes
If Applications Cannot Find License File

As a default, License Application Manager (LAM) expects the license
file to have a pathname of $OWHOME/lam/license.dat .
Environment variables locating the license are normally set up by the

installation program. The variable can contain either the full path to the
license file including the machine name on which it resides, or it can
contain the port number and machine name of the license server that
serves that license file. For example:
LM_LICENSE_FILE 2013@HostName
or
LM_LICENSE_FILE $OWHOME/lam/license.dat
FLEXlm performs background operations to speed-optimize access to

the license file when it is run from an application for the first time.
FLEXlm writes the path to the license file in either the user home
directory or the root directory (depending on the platform and
configuration) in a hidden file named .flexlmrc.
If it is necessary to change the location or name of the license file being

used, remove .flexlmrc in order to get FLEXlm to use the new license
file if the path has changed.
Overriding LM_LICENSE_FILE
Landmark generally makes use of the LM_LICENSE_FILE
environment variable. Applications running for the first time may
incorrectly override the setting of the LM_LICENSE_FILE variable.
Set the environment variable

FLEXLM_NO_CKOUT_INSTALL_LIC to 1.
Doing this will prevent the creation of $HOME/.flexlmrc. You should

also remove any existing $HOME/.flexlmrc to avoid overriding
LM_LICENSE_FILE.

Restricting the Use of FLEXlm Utilities

The lmdown, lmremove, and lmreread utilities can be privileged,
depending on the switches used when the lmgrd license server is
started. When they are privileged, only a License Administrator can run
the utilities. A License Administrator is a member of the lmadmin
group, or if the lmadmin group does not exist, a License Administrator
is a member of the group with ID 0.
To restrict who can run the utilities, lmgrd license server must be
started with the -2 -p switch. For instance to start the server and restrict
the use of the utilities, you might enter the following:
$OWHOME/lam/bin/startlmgrd -c /export/home/license/license.dat -2 -p
If you want to disable the lmdown or lmremove utilities, so that even a

License Administrator can not run them, the lmgrd license server can
be started with -x UtilityName . For example, you might enter one of
the following commands:
$OWHOME/lam/bin/startlmgrd -c /export/home/license/license.dat -x lmdown
$OWHOME/lam/bin/startlmgrd -c /export/home/license/license.dat -x lmremove
$OWHOME/lam/bin/startlmgrd -c /export/home/license/license.dat -x lmdown -x lmremove
After disabling lmdown, you can only stop the lmgrd license server
with the kill command, but you must not use the version of the
command with the -9 switch.
For more information, see the FLEXlm documentation on the

GLOBEtrotter Software website.
http://www.globetrotter.com/manual.htmContains the Table of

Contents of the FLEXlm End Users Guide.
http://www.globetrotter.com/IX.htmContains the Index and a link to

download a PDF of the FLEXlm End Users Guide.

Setting the Environment
Setting the Users Environment

The following should be done to set the users environment:
Create a user (if an appropriate user does not exist).
Set the default shell to csh (recommended).
Without OpenWorks
For users to submit simulation jobs from a Windows 2000 machine to a remote
UNIX or Linux machine, the location of the UNIX/Linux VIP installation and the
location of the License Manager must be known. This information is provided in
a .kviprc file that a user has in his home directory or the site administrator has
placed in /etc or /usr/local/etc directories. A template of this file is
located in the UNIX and Linux VIP installation and is found in the top VIP
directory.
If it is to be placed in the users home directory, make a copy of this file and
rename it to .kviprc (note the dot before the name). If the site administrator has
placed it in /etc or /usr/local/etc, the dot before the name is not required.
Edit the copied file and modify the location of the VIP UNIX or Linux installation
(VIPHOME) and the location of the License Managers license.dat file
(LM_LICENSE_FILE).
VIP 2003.4 Unix/Linux Release Notes Page 43 Setting the Environment

Other Important Environment Variables
Simulator Selection Environment Variables - Default Executables
Starting DESKTOP-VIP for Windows 2000 will set the following simulator
default environment variables:
Variable Name Default Simulator Name Description Platform
VIPCOREDEF core2003r4.exe Defaulted name of VIP-CORE ALL

executable
VIPEXECDEF exec2003r4.exe Defaulted name of VIP-EXEC ALL

executable
VIPCORELOCALDEF pcore2003r4_local.exe Defaulted name of Parallel VIP- IBM

CORE executable running local
VIPEXECLOCALDEF pexec2003r4_local.exe Defaulted name of Parallel VIP- IBM

EXEC executable running local
VIPCOREDISTDEF pcore2003r4_dist.exe Defaulted name of Parallel VIP- WINDOWS. SUN,

CORE executable running dis- SGI, LINUX
tributed
VIPEXECDISTDEF pexec2003r4_dist.exe Defaulted name of Parallel VIP- WINDOWS. SUN,

EXEC executable running dis- SGI, LINUX
tributed
If a user chooses to use a different simulator, the particular simulator name can be
changed by setting the appropriate variable before starting DESKTOP-VIP. Or the
user can switch between simulator versions on the Job Submittal panel.
Note that the default simulator name version numbers are no longer different for
the Linux executables.

If a user chooses to use a different simulator, he can change the particular

simulator name by setting one of the following environment variables in his
.krunvip file:
setenv VIPCOREDEF newcore.exe

setenv VIPEXECDEF newexec.exe
setenv VIPCORELOCALDEF newpcorelocal.exe

setenv VIPEXECLOCALDEF newpexeclocal.exe
setenv VIPCOREDISTDEF newpcoredist.exe
setenv VIPEXECDISTDEF newpexecdistexe


Appendix A: Parallel Computing
Getting Started with PARALLEL-VIP

Setting up your system to run PARALLEL-VIP may require some changes to your
basic system configuration. This section describes nomenclature and other
information to facilitate the installation.
Parallel Computing Quick Guide
Refer to the Parallel Computing chapter of the Getting Started manual for a helpful
introduction to parallel computing.
Include File Configuration Requirements

Each possible parallel configuration has associated requirements for valid
include file locations and configuration requirements. Configurations and
requirements are detailed in the PDF document IncludeFileRules.pdf which can
be accessed from the Help menu (Help > Submit > Include Paths).
Configurations are also provided in Excel spreadsheet format in the document
BoulderSubmission.xls. Both documents can be found in
%VIPHOME%\doc\help.
Warning
Be sure to read the IncludeFileRules document carefully. This document provides a spreadsheet
to help you find your configuration options and the setup rules that must be met.
Which Systems Will Parallel-VIP Run On?

PARALLEL-VIP will run on the following systems:
1. IBM SP workstations with a Power 2 architecture with or without a high

performance switch. This configuration is often referred to as a LOCAL
system. The IBM software POE and PSSP must be installed.
2. Shared Memory Silicon Graphics workstations (Power Challenge, Octane,

and Origin 2000). This configuration is often referred to as a
DISTRIBUTED system.
3. Shared memory SUN Solaris workstations. This configuration is often

referred to as a DISTRIBUTED system.
VIP 2003.4 Unix/Linux Release Notes Page 47 Appendix A: Parallel Computing

4. Linux Red Hat 7.2 cluster workstations. This configuration is often referred
to as a DISTRIBUTED system.
Where Should You Run From?
Running on IBM SP Workstations
A user can either:
1. Log in directly to one of the SP nodes and submit the run from the command
line.
2. Submit the run remotely from your Windows 2000 machine.
NOTE: IBM's Parallel Operating Environment (POE) must be running on the SP

system.
See Appendix E: SP2 POE Checkout Guidelines for SP POE checkout

guidelines and helpful hints.
Running on Shared Memory Silicon Graphics, Solaris, and Linux Worksta-

tions
A user can either:
1. Log onto the Silicon Graphics, Solaris, or Linux shared memory machine and
submit the run from the command line.
2. Submit the run remotely from your Windows 2000 Machine.
NOTE: MPI (Argonne N.L. Version 1.1) needs to be accessible from the submitting
machine. The code is provided with the Desktop-VIP installation.
File System Set Up

The directories containing the VIP installation and the VIP dataset need to be
cross-mounted with all the nodes that will be used to run the calculation. In
addition, the file systems where the VIP installation and the datasets to be run
reside must each be mounted and accessible using the same full path name for all
the nodes.
For example, lets assume that the VIP home directory ($VIPHOME) is located at
/mnt/vip on the first node. Then the same directory must be cross mounted and
named so it has the same full path name on all the remaining nodes. Any errors
you receive may not be very descriptive of the underlying problem if the file

systems are not mounted correctly. Refer to Appendix B for NFS mounting
requirements.
NOTE: It is highly recommended that all user files are located on a local disk and
not on a NFS mounted disk. This will reduce and possibly eliminate NFS
read/write errors which could cause abnormal termination of runs and/or
corrupt data files. This is manditory for SGI, Solaris, and Linux Shared
Memory workstations.

.rhosts File
You must be able to remotely log in to the nodes that will be used to run
PARALLEL-VIP without entering a password. This requires that you have a
.rhosts file in your home directory containing the names of all the nodes you want
to be able to access or that your administrator has modified the /etc/hosts file. A
sample .rhosts file is shown below.
Sample .rhosts file:
#
#ptype ibmsp IBM SP
#interface us User Space Comm. (us)
xyzsw1.lgc.com
xyzsw2.lgc.com
xyzsw3.lgc.com
xyzsw4.lgc.com
#interface ip Local IP Comm. (ip)
xyzen1.lgc.com
xyzen2.lgc.com
xyzen3.lgc.com
xyzen4.lgc.com
xyz2en1.lgc.com
xyz2en2.lgc.com
xyz2en3.lgc.com
xyz2en4.lgc.com
#ptype sgishm SGI Shared Memory
sgi1.lgc.com
#ptype generic Generic Hosts
ibm1.lgc.com
ibm2.lgc.com
#ptype linux Linux Shared Memory
lin1.lgc.com
lin2.lgc.com
#endptype
NOTE: The # is used to indicate comments which are not interpreted by the UNIX or
Linux operating systems.
The #ptype, #interface and #endptype keywords are recognized by the

PARALLEL-VIP job submission system and used to delimit the different
types of nodes available on the system.
The list of nodes and cpu's in the .rhosts file must contain the complete
domain name. In this example xyz2en1.lgc.com is a valid name, while
xyz2en1 is invalid.
Remote Shell Capabilities

A PARALLEL-VIP job submission uses the remote shell (rsh) capabilities of
UNIX and Linux. In developing the applications it has been assumed that a rsh
command will return only the command information. This means that all of the
nodes that can be accessed by PARALLEL-VIP cannot return extraneous echo

commands in the .cshrc file. Consider the following two of .cshrc files. The first
one is valid, while the second one is invalid for running PARALLEL-VIP.
Sample of Valid .cshrc file:
#!/bin/csh
set path =($path .)
#
if ($?prompt) then
if (-e $LM_LICENSE_FILE) then
echo License File is present
else
echo License File is missing
endif
endif
Sample of Invalid .cshrc file:
#!/bin/csh
set path =($path .)
#
if (-e $LM_LICENSE_FILE) then
echo License File is present
else
echo License File is missing
endif
The invalid file contains an echo command that is invoked anytime, while the
valid file performs a test to ensure that the echo command is performed only for
interactive sessions. Although this distinction is unnecessary for the serial version
of VIP it is very important here.
NOTE: The terms valid and invalid are used here only for the perspective of
whether PARALLEL-VIP can be run; both these files are valid from a
UNIX/Linux perspective.
Testing for Valid rsh Performance

The easiest way to test for valid rsh performance is to perform a simple rsh
command on all of the accessible nodes. For example, a remote shell to get the
date should return just the results of the date command. If anything else is
returned, then the .cshrc file is invalid and the PARALLEL-VIP job submission
scripts will not function correctly.

For example, consider that you want to run PARALLEL-VIP on the node known
as vip2en1. Using a rsh command to determine the date with the Invalid .cshrc
file listed above will return the following:
% rsh vip2en1 date

License File is present
Thu Jun 12 13:09:22 CDT 1997
The presence of additional information beyond what is normally returned by

the date command indicates a problem!!
Using a rsh command to determine the date with the Valid .cshrc file listed above
will return the following:
% rsh xyz2en1 date

Thu Jun 12 13:09:22 CDT 1997
The lack of additional information beyond what is normally returned by the

date command indicates that the PARALLEL-VIP job submission should
work.
Other Notes
PARALLEL-VIP carries memory overhead which scales with the total number of
gridblocks in the simulation (NB). The program uses 2 extra arrays, each of
dimension NB, per processor. This overhead is quite minimal when running on a
distributed memory machine, but can become quite large when running on a
shared memory system.

Appendix B: NFS Mounting Requirements for
Parallel or Remote Submission
In order for Parallel or Remote Job submission to be fully functional, it is required
that:
1. For any given directory path, there should be at least one common directory
path name for ALL the nodes;
2. There is a consistent way to generate this common directory path name on

ANY of the nodes.
We can satisfy these two requirements in two different ways: 1) Manual mounts
and 2) Automounter:
The following sections describe the restrictions for each methods.
Manual Mounts
It is necessary that the result of /bin/pwd on ALL of the nodes/machines is a
common directory path name.
Assumptions
Machine Alpha - Contains physical disks mounted as filesystems:
/u1 and /u2.
- These filesystems are exported to other
machines as:
/u1 and /u2
Machine Beta - Mounts the filesystems as /u1 and /u2 using the
commands:
mount Alpha:/u1 /u1
mount Alpha:/u2 /u2
Tests
1. A user logs onto Alpha. At the prompts, Alpha%, he types in:
Alpha% cd /u1/some/sub/directory
Alpha% /bin/pwd
He would see the following on his screen:

/u1/some/sub/directory
VIP 2003.4 Unix/Linux Release Notes Page 53 NFS Mounting Requirements

2. A user logs onto Beta. At the prompts, Beta%, he types in :

Beta% cd /u1/some/sub/directory
Beta% /bin/pwd

WARNING: There is a common practice that NFS mounted filesystems will look the
same; i.e., /bin/pwd would generate a common path name for all NFS
clients. The exception to this practice is on NFS servers, where symbolic
links (i.e. "ln -s") are used to access common path names. There is no
consistent way to generate a common path name from the result of /bin/
pwd on NFS servers; e.g., /bin/pwd would report /arbitrary/path/
name, to which a symlink /common/path/name is pointed. There is no
consistent way to derive a /common/path/name from a /arbitrary/
path/name except for ugly hacks. Hence Requirement 2 above would not
be satisfied. On such systems DTOP submissions will still work as long as
NFS servers are not among the simulation nodes/machines.
Automount Mounts
Automount (assuming all the involved filesystems are exported), such that;
1. For NFS servers, /bin/pwd would report a /arbitrary/path/name, from

which a common path name /net/node/arbitrary/path/name can be derived.
NFS servers are the machines where the filesystems are mounted locally.
2. For NFS clients, /bin/pwd would report either a /common/path/name (for

recent autofs configurations) or /tmp_mnt/common/path/name (for vanilla
automounter), from which a common path name
/common/path/name can be derived. For the vanilla automounter, NFS
clients would report either:
a. /tmp_mnt/net/machine/common/path/name
b. /tmp_mnt/home/machine/userID/common/path/name
Assumptions
Machine Alpha - Contains physical disks mounted as filesytems
/u1 and /u2
These filesystems are exported to the world.
Machine Beta - Automounter has mounted the filesystems

/u1 and /u2

Tests
1. A user logs onto Alpha. At the prompts, Alpha%, he types in:
Alpha% cd /u1/some/sub/directory
Alpha% /bin/pwd

He also types in:

Alpha% cd /net/Alpha/u1/some/sub/directory
Alpha% /bin/pwd
He would again see the following on his screen:

NOTE: Automounter has automatically taken care of the linkages.
2. A user logs onto Beta. At the prompts, Beta%, he types in:

Beta% cd /net/Alpha/u1/some/sub/directory
Beta% /bin/pwd

/tmp_mnt/net/Alpha/u1/some/sub/directory
NOTE: The DESKTOP-VIP Submission scripts will automatically delete

/tmp_mnt from the directory path name. What is left is a /common/path/
name; i.e. /net/Alpha/u1/some/sub/directory. This directory path is
recognized on both machines.
Environment Variables and Guidelines

For sites that have customized the automount naming conventions, the following
environmental variables may be used to reconfigure the prefixes:
Automount Default
VIPNFSTMPMNTDIR /tmp_mnt
VIPNFSAUTO "not set"
DESKTOP-VIP will try to determine the automount configuration by parsing NIS

automount maps. It assumes the following with the following limitations:
1. The customers site is running NIS or NIS+.
2. The customers site has a NIS map auto.master.

Limitation:
1. DESKTOP-VIP does not support command line options for automount

daemon that override auto.master.
In order for DESKTOP-VIP to work, the customers site must have an /dir to -
hosts map entry in auto.master. Typical entry maps hosts to -hosts. Customized
directory names are permitted; typical directory names include /net, /nfs, /remote,
etc.
Rules
1. If VIPNFSAUTO is set to "no", "NO", or "0", then the path normalization for
automounter is disabled.
2. If VIPNFSAUTO is set to any other values from "no", "NO", or "0", then the
path normalization for automounter is enabled.
3. If VIPNFSAUTO is not set, DESKTOP-VIP will attempt to determine

whether automount is running by looking for the automount daemon and then
run with the defaults described in the table above.

Appendix C: Setup Instructions to Submit Jobs
via Remote Shell
Overview
DESKTOP-VIP Version 2003.4 will supply pre/post applications on Windows
2000 platform only. The only applications provided on UNIX and Linux will be
serial and parallel simulators. The implication of this structure is that all
simulation jobs, both serial and parallel, will be submitted from the Windows
2000 machine. A user can submit jobs locally, remotely to another Windows 2000
machine, or remotely to a UNIX or Linux machine.
For remote submittal to work properly, the machines (Windows 2000 and UNIX
or Linux ) must be able to communicate to each other using remote-copy (rcp)
and remote-shell (rsh) commands. They must be able to ping each other
without having to know the Internet Protocol (IP) address of the other machine.
For this reason Name Resolution is one of the critical requirements for remote
submittal to work properly.
Typically there are two types of network systems that are found in our customers
offices. The first is geared to larger companies who are using a fully integrated
network made up of name servers: DNS (Windows 2000/UNIX or Linux) or
WINS (NT) utilizing the dynamic host configuration protocol (DHCP). They will
have both Windows and UNIX/Linux machines on a single network with dynamic
IP addressing. The second type is geared to a small business that has a simple
network, is not made up of servers and has fixed IP addresses and naming
conventions. The small business network may also include Windows, UNIX, and
Linux machines.
For large and complex networks, the following simplified diagram (Figure 1)
represents the components required for Name Resolution of devices dynamically
across the network.
VIP 2003.4 Unix/Linux Release Notes Page 57 Appendix C: Setup Instructions to Submit Jobs via
NT Win2K UNIX/
Linux
Client Client
Client
NT Server Windows 2000/UNIX /Linux Server

WINS DNS
DHCP Protocol
Figure 1
Every client machine in this architecture can ping the other by name and does not
have to know the IP address of the other machine. The DNS server works in
conjunction with the WINS server to resolve the IP and naming convention. This
is critical because if both NT and Windows 2000 machines are using DHCP to
determine their IP addresses, these IP addresses can change at any time.
The second, simple type of network is one in which there are no network servers
or, if there are, they are not running DNS and not using DHCP. Typically, the IP
address and name of each machine will not change over time. In this case, the
user can modify the /etc/HOSTS file on the UNIX or Linux machines and the
C:\winnt\system32\drivers\etc\HOSTS file on the Windows 2000 machines to
specify the IP and hostname relationships.
Assumptions: About the Users Network

The TCP/IP protocol will be the sole means of communication between the
different machines.
The machines must be assigned static IP addresses or addresses must be
assigned dynamically via DHCP. In either case, the DNS server on the
network should have a proper record of the fully qualified and unqualified
hostname for all machines. For example, if your domain is company.com and
the machines name is machine, then the DNS should have proper records of
both machine and machine.company.com that point to the same IP address.
If there is no DNS or it is not properly configured, then each local and remote
machine must have a record of every other machines qualified and
unqualified hostname in the respective machines HOSTS file. On UNIX or
Linux machines, this file can be found in the /etc directory. On Windows 2000
machines, this file can be found in the C:\winnt\system32\drivers\etc
directory.
Notes
The user must have root (UNIX) or administrator (Windows 2000) privileges to
modify the HOSTS file.
Key Commands
ping Command This command is used to check the communications
between the different machines on the network. It can be found in the
following locations:
SGI, Solaris, IBM, Linux - /usr/etc/ping
Windows 2000 C:\winnt\system32\ping.exe
It can be executed as follows:
ping machinename
If the network has not been set up properly, then errors such as Time Out or
Connection refused will be given. If this happens then either check the DNS
server in a resolution network or add the proper IP address and qualified/
unqualified hostname information in the respective hosts files for the static IP
networks. On Solaris machines, you may also have to edit the /etc/
nsswitch.conf file to remove the {NOTFOUND=return} parameter on the
line containing the keyword hosts:.
rsh & rcp Commands The DESKTOP-VIP job submittal application uses
rsh and rcp commands to execute commands on the remote UNIX or Linux
machine and to copy files to/from the local Windows 2000 machine to the
remote UNIX or Linux machine. For these operations to work properly, it is
required for the user to be able to login from the local Windows 2000 machine
to the remote UNIX or Linux machine without entering a password. A user
can determine if a password is required on the UNIX or Linux machine by
trying to rsh to the UNIX or Linux machine from a Windows 2000 machine
by typing the following command:
C:\winnt\system32\rsh UnixLinuxmachinename l UnixLinuxusername hostname
If this command returns with the Unix/Linuzmachinename, then everything

should be set up properly. If it fails, then check to see if there is an entry in
the UNIX or Linux machines /etc/hosts.equiv file or the users .rhosts file
located in his home directory on the UNIX/Linux machine containing the
Windows2000machinename and the Windows2000username. The /etc/
hosts.equiv file and the users .rhosts file contain entries that denote which
machines and users can serve as remote hosts. Be certain that qualified and
unqualified machine names are specified..
VIPrshClient Command - The DESKTOP-VIP job submittal application

uses the VIPrshClient command to execute commands on remote Windows
2000 machines and to copy files to/from the local Windows 2000 machine to
the remote Windows 2000 machine. It is meant to operate much like the Unix/
Linux rsh and rcp commands described above. It communicates with
VIPrshServer running on the remote machine. Refer to Appendix C for a
detailed description of these two programs. To determine if the
communication between the local and remote machines is set up properly, a
user can type in the following command from the
%VIPHOME%\dtvip\exec directory:
VIPrshClient Windows2000machine l Windows2000username n hostname
If it returns with the Windows2000machine name, then everything should be

setup properly. If it fails, then check to see if the remote machines
VIPrshServer service as been stopped.
Key Files
hosts file This is a system file that contains the IP address-hostname
database information. It can be found in the following locations:
SGI - /etc/hosts
Solaris - /etc/hosts
IBM - /etc/hosts
Linux - /etc/hosts
Windows 2000 C:\winnt\system32\drivers\etc\hosts
For networks that do not have DNS servers, these files must be modified to
reflect the IP address-hostname relations of the various machines that will
be communicating with each other. To test that the machines can see each
other use the ping command described above. You should enter both the
fully-qualified and unqualified hostname for all machines, both local and
remote. The hosts file on the Windows 2000 machine should contain the IP
address-hostname of the UNIX or Linux machines. The hosts file on the
UNIX or Linux machine should contain the IP address-hostname
relationships of the Windows 2000 machines. For more information on the
hosts file, perform a man hosts command on a UNIX or Linux machine.
Figure 2 is a sample of a hosts file showing a new entry for the domain
company.com and the machines name machine:
#Copyright (c) 1993-1999 Microsoft Corp.

#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
127.0.0.1localhost
164.132.32.01 machine.company.com machine
Figure 2
.rhosts and hosts.equiv files These are UNIX or Linux system files
that define which users on remote machines are permitted to remotely execute
commands on the local machine. When setup properly, rlogin does not
prompt for a password on the UNIX or Linux machine and the rsh command
will complete successfully on the Window 2000 machines. The hosts.equiv
file is located in the /etc directory on the UNIX or Linux machines. Users may
expand this authentication scheme based upon trusted hosts by installing a
.rhosts file in their login directory. For more information, perform a man
rhosts command on a UNIX or Linux machine.
Figure 3 is a sample hosts.equiv file that describes some of the other

authentication schemes that are permitted. These schemes are also used in the
.rhosts file. For example, we have added the Windows 2000 machines name
Window2000machine and the Windows 2000 users name
Windows2000username to the bottom of the file. Please note, that both fully-
qualified and unqualified machine names were entered.
#@(#)611.5 src/tcpip/etc/hosts.equiv, tcpip, tcpip430, 9737A_430 9/27/91 17:11:34

# IBM_PROLOG_BEGIN_TAG
# This is an automatically generated prolog.
#
# tcpip430 src/tcpip/etc/hosts.equiv 1.5
#
# Licensed Materials - Property of IBM
#
# (C) COPYRIGHT International Business Machines Corp. 1985,1989
# All Rights Reserved
#
# US Government Users Restricted Rights - Use, duplication or
# disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
#
# IBM_PROLOG_END_TAG
#
# COMPONENT_NAME: TCPIP hosts.equiv
#
# FUNCTIONS:
#
# ORIGINS: 26 27
#
# (C) COPYRIGHT International Business Machines Corp. 1985, 1989
# All Rights Reserved
# Licensed Materials - Property of IBM
#
# US Government Users Restricted Rights - Use, duplication or
# disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
#
# /etc/hosts.equiv
#
# This file, along with a local user's $HOME/.rhosts file, defines which
# users on foreign hosts are permitted to remotely execute commands on
# your host. The rshd, rlogind, lpd, and srcmstr programs all use this
# file to determine remote user access.
#
# The format of this file is as follows:
#
# hostname [username]
#
# Both hostname and username can be preceded by a '-' character to deny
# access. A '+' character can be used in place of hostname or username
# to match any host or user. If you are using NIS, both the hostname and
# username may be in the form:
#
# +@netgroup
# -@netgroup
#
# where "netgroup" is an NIS netgroup defined in the netgroup map. The
# '+' form allows access to any host or user in the netgroup, while the
# '-' form denies access to any host or user in the netgroup.
#
# Lines beginning with a '#' character and blank lines are ignored.
#
# Examples:
#
# host user allows access to user on host
# + user allows access to user on any host
# host -user denies access to user on host
# -host denies access to all users on host
# -@group denies access to all users on hosts in group
# +@group1 +@group2allows access to users in group2 on hosts in group
Windows2000machine.company.com Windows2000username
Windows2000machine Windows2000username
Figure 3
VIPrshUsers.txt file This is a Windows 2000 file that performs the same
type of function as the .rhosts and hosts.equiv files on UNIX or Linux. A
template of this file called VIPrshUsers.temp.txt is located in the
%VIPHOME%\dtvip\exec directory for the users to modify. If a
VIPrshUsers.txt file is found on the VIPrshServer machine in the
%VIPHOME%\dtvip\exec directory, the server will limit access to only the
users defined in the file. Figure 4 is a sample of the template file:
#VIPrshUsers.temp.txt
# This is a template for an actual VIPrshUsers.txt username/password file

# as is used by the VIPrshServer for remote Windows-to-Windows requests.
# The VIPrshUsers.txt file must be in the VIPEXEC directory.
# List usernames that should be able to gain remote access.

# VIPrshServer IS CASE SENSITIVE!!
jSmith001
JohnBigBoot
AdminFromHeaven
# Note that the usernames are simply text strings passed by the
# VIPrshClient. They do not need to be 'true' network usernames.
# This allows you to use a more obscure word than your username
# much like a password.
# So, instead of executing:
# VIPrshClient RMTHOST -l joesmith . . .
# You can instead use:

# VIPrshClient RMTHOST -l passwdABC123 . . .
# This way simply knowing a username is not enough to access a Server.

# Simply list whatever obscure word(s) you would like to use.
passXYZ
26Dec1941
2cupsInaPint2PintsInMyCup
Figure 4
.kviprc file For users to submit remote simulation jobs from a Windows
2000 machine to a remote UNIX or Linux machine, the location of the UNIX/
Linux VIP installation and the location of the License Manager must be
known. This information is provided in a .kviprc file that a user has placed in
his home directory on UNIX or Linux, or the site administrator had placed in
the /etc or /usr/local/etc directory. A template of this file (kviprc) is located
in the UNIX/Linux VIP installation and is found in the top /vip directory.
If the file is to be placed in the users home directory, make a copy of this file
and rename it to .kviprc (Note the dot before the name). If the site
administrator has placed this file in either the /etc or /usr/local/etc directory,
the dot before the name should not be used.
Edit the file .kviprc and modify the following lines to point to the actual
location of the UNIX or Linux installation and the license.dat file:
setenv $VIPHOME /usr/apps/vip

setenv LM_LICENSE_FILE $VIPHOME/licmgr/license.dat
Please notice that there should be a section for each UNIX or Linux machine
type on the network. Figure 5 represents a sample of the template file with
sections for Linux IBM, SGI, and SUN systems.
Known issue:
Linux does not honor the setting of TMPDIR and therefore all temporary/
scratched files will be placed under /tmp. The user should have sufficient
temporary space in /tmp to handle the particular problem he is trying to
simulate.
#!/bin/sh
# Startup file for VIP submissions.
# spf 10/09/2001
# The locations of VIPHOME and LM_LICENSE_FILE given below are only examples.
# Modify the location of VIPHOME and LM_LICENSE_FILE to reflect your particular
# installation. Please note that there are sections for the different Unix
# platforms. Please modify the one that is appropriate.
# Platform-specific commands
platform=`uname`
# ++++++++++++++++++ IBM Platform +++++++++++++++++++
if (test "$platform" = "AIX") then

VIPHOME=/usr/apps/vip
export VIPHOME
. $VIPHOME/krun.vip
LM_LICENSE_FILE=$VIPHOME/licmgr/license.dat
export LM_LICENSE_FILE
# ++++++++++++++++++ SGI Platform +++++++++++++++++++
elif (test "$platform" = "IRIX64") then

export VIPHOME
. $VIPHOME/krun.vip
# ++++++++++++++++++ SOLARIS Platform +++++++++++++++
elif (test "$platform" = "SunOS") then

export VIPHOME
. $VIPHOME/krun.vip
# ++++++++++++++++++ LINUX Platform +++++++++++++++++
elif (test "$platform" = "Linux") then

export VIPHOME
. $VIPHOME/krun.vip
# elif ([["$platform" = "Windows*"]]) then

# Put any Windows-specific commands here.
else
echo "$platform is not supported by VIP"
echo "Calling EXIT"
exit
fi
# Platform-independent commands
if (test "$TMPDIR" = "") then

TMPDIR=.
export TMPDIR
fi
if (test "$ERR_LEVEL" = "") then
ERR_LEVEL=4
export ERR_LEVEL
fi
PATH=$PATH:.
export PATH
Figure 5
Job Submission Panels

The job submission panels on the Windows 2000 machine have locations to enter
your login name on the remote machine (necessary if it is different from the local
system), the name of the remote machine, and the location of the temporary
workspace on the remote machine. It is mandatory that you fill in these fields
correctly and then perform a carriage return. Please refer to the VIP Job
Submission document for a complete description of the job submission panels.
Restrictions
If the include files are located on UNIX or Linux, the include with *i.dat and
*r.dat must be to the exact location of the files. Relative paths are prone to
problems. When in doubt, always specify the full qualified path to the include
file.
Appendix E: SP2 POE Checkout Guidelines
1. To check POE installation and compatible release level for each IBM-SP node
type in:
lslpp -h bos.rte ppe.poe ssp.basic
If everything is installed properly than you would get the following response:
Fileset Level Action Status

Path: /usr/lib/objrepos
bos.rte
4.3.3.0 COMMIT COMPLETE
ppe.poe
ssp.basic
Path: /etc/objrepos
bos.rte
4.3:3.0 COMMIT COMPLETE
ppe.poe
ssp.basic
Current tested installed release levels at Landmark are:
AIX 4.3.3
POE 2.4
PSSP 3.1.1
POE and SSP levels must be in sync.
2. The parameters set in the limits file found in /etc/security should all be set to
unlimited (-1). For example:
Wrong Correct
fsize= 4097151 -1
core= 2048 -1
data= -1 -1
rss= 0 -1
stack= 0 -1
VIP 2003.4 Unix/Linux Release Notes Page 69 Appendix E: SP2 POE Checkout Guidelines
3. To make a first trivial check of POE working:
a. Login to a node
b. Create a host.list file which contains one line specifying a node.domain

name, e.g. xyz2en5.lgc.com.
c. Type in:
poe date -ilevel 0
The date will be returned. If it fails, then try setting ilevel to 6 to increase
the amount of messages. One possible failure is because a resource limit
was not set (See item 2 above)
4. The directory to the data must have the same path on all nodes. If the data is
resident on one node and mounted on the other nodes, a link must be used on
the node where the data resides. For example:
Resident Directory: /u7/rtartcd

Mounted Directory: /tmp_mnt/home/rtartcd
Then on the node where the data resides, under /tmp_mnt/home:
Enter:
ln -s /u7/rtartcd /tmp_mnt/home/rtartcd
Please refer to Appendix B for further discussion of NFS mounts.
5. IP addresses, node names, and aliases are defined in the /etc/hosts file. It must
be same on all nodes. Once logged on to one node, you must be able to rlogin
or rsh to any other node using any external ethernet, internal ethernet, or
switch domain names. Fully qualified domain names for each of these
domain names must exist in the user's ~/.rhosts file. See Appendix A.
6. To check the bandwidth between each pair of nodes:
A bandwidth test provided by IBM is located in the following directory:
/vip/dtvip/sim/bwtool
To execute the test:
a. Edit the file twonode.list and replace the nodes with your set of
node.domain names.
b. Type in
bwloop -f twonode.list -m ip
This will test the bandwidth between each pair of nodes found in the
twonode.list file.
Typically one should observed the following:
IP Mode 18 mbytes/sec
Ethernet 1.2 mbytes/sec
7. If the switches are "unfenced" while a parallel job is running, the job will
abort.
Appendix F: Modifying a Samba Server to Work
with VIP Applications
DESKTOP-VIP R2003.4 was certified with Samba 2.2.5. An example Samba
configuration file used during testing is also provided in this appendix. When
setting up your Samba installation, please adhere to the sections below to ensure
that a Samba Server will work with VIP applications. The following procedures
are best performed when logged in to the Samba server machine as root.
For further information, please refer to the following:
Example Samba configuration file supplied with your installation of

Samba: /pub/tools/samba/latest/lib/smb.conf
Samba configuration man page: man smb.conf
Samba website: http://www.samba.org/
4. The Samba how-to documentation: http://us1.samba.org/samba/ftp/docs/

htmldocs/Samba-HOWTO-Collection.html
Using Samba shares in Remote Windows VIP Submissions or

Parallel Windows VIP Submissions
Remote Windows VIP Submissions run using the VIPrshServer Service. Parallel
Windows VIP Submissions run using the Patent MPI Service. The recommended
way to have each of these Windows services running is under the Administrator
account. Though the administrator account has proper access to the local
Windows system and most Windows network shares, it is denied access to Samba
shares by default, because it is not a proper Unix user. Perform the following
steps to change the default:
1. In your Samba Configuration file (smb.conf), add the following setting to the
[global] section:
username map = /usr/local/samba/lib/users.map
You can change the path and filename to any that you desire, that given above
is just one possible example.
2. Create a text file in that location and add the following line within it:
unixuser = administrator
Change unixuser to the username of an existing unix user. You cannot leave
it as unixuser.
VIP 2003.4 Unix/Linux Release Notes Page 73 Modifying a Samba Server

3. Set your unixuser to accept the Windows password passed with

administrator using the Samba smbpasswd utility. This utility is located in the
/bin directory of your Samba installation:
/pub/tools/samba/latest/bin/smbpasswd a unixuser
The utility will then prompt you to type and retype the password type the
password for the Windows administrator. Again, please type a proper
username, not unixuser.
Please note that this will only allow one password authentication for all Windows
Administrators. Therefore, if each administrator on each Windows machine has a
unique password, it will not work. If thats the case, then youre better off running
the VIPrshServer and Patent MPI services as unique users with administrative
privileges, and setting up the access of those users to Samba shares as needed.
Using Samba Versions 2.2.2 and Higher with VIP applications.

Normally, VIP applications can utilize files and directories shared by a Samba
server with the same accessibility as the logged-on user. However, with Samba
versions 2.2.2 and higher, two settings do need to be set in the Samba
configuration file in order to allow VIP applications properly access.
Beginning with version 2.2.2, Samba assumes the client computer to be running
programs that understand Microsoft Windows NT communication and error
protocol. Some VIP applications depend upon third party software that can not
recognize these New Techology codes. Unless these protocol are turned off (and
older, more standard protocol used), VIP applications may not be able to open,
change or create files on a Samba share.
If you are running VIP and need access to shares made with Samba version 2.2.2
or higher, the following changes to the Samba configuration file (smb.conf) will
correct the problem. In the [global] section, add:
nt smb support = no
nt status support = no
The first parameter will turn off New Technology (NT) Server Message Block
(SMB) protocol support. This simply switches to the older, more standard
protocol that has been used for LAN communication for years. In fact, using the
older protocol culls the amount of messaging and the complexity of the
interpretters used, so communication is faster. This speedup is analogous to that
seen in Reduced Instruction Set Computers (RISC).
The second parameter turns off the passing of NT error codes by Samba. If this
parameter is left on, when a client attempts to access a file, a complex error or no-
error code is sent. Applications that are not made to interpret such a complex
code may simply assume that it is an error, and access to the file will be canceled.
Turning off the NT Status Support option will force Samba to fall back on more

general, less complex error codes, ensuring that more applications understand
them.
Example smb.conf File Used During Testing

The example file is provided on the following page. You can copy and edit this
file to conform to your local setup. Note that asterisks (#) at the beginning of the
line indicate a comment line.

## Anything in the global section applies to all shared dirs

# Option #1:
# The following lines setup password authentication to happen
# on the NT Domain Controller
#
[global]
security = server
password server = yourserver
workgroup = HOUSTON
log file = /var/adm/samba/log.%m
wins server = 111.222.33.44
username map = /var/adm/samba/username.map
encrypt passwords = yes
socket options = TCP_NODELAY
nt status support = no
nt smb support = no
lock directory = /var/samba/locks
## The higher the debug level, the faster the log gets big. And
## it gets big really fast
max log size = 5000
## Can be anywhere from 0-10. 5 is pretty verbose...
debug level = 2
## For case mangling
preserve case = yes
short preserve case = yes
case sensitive = yes
## here is an example for any other directories you want to
share
#
[stoic]
browseable = yes
writeable = yes
public = yes
path = /export/home
#
[pa]
browseable = yes
writeable = yes
public = yes
path = /pa
#
#Dont forget to stop and restart Samba!

Unix Release Notes

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Unix Release Notes

Încărcat de

Drepturi de autor:

Formate disponibile

Landmark Desktop-VIP

VIP Simulators 2003.4

Landmark/Asia Pacific Landmark/EAME Landmark/The Americas

VIP 2003.3.0 UNIX/Linux Release Notes Page 1 December 2001

VIP 2003.3.0 UNIX/Linux Release Notes Page 2 December 2001

Enhancements and New Features

VIP 2003.4 Unix/Linux Release Notes Page 3

LAM License Manager

Setting the Environment

VIP 2003.4 Unix/Linux Release Notes Page 4

Appendix A: Parallel Computing

Appendix B: NFS Mounting Requirements for Parallel or Remote Submission

Appendix C: Setup Instructions to Submit Jobs via Remote Shell

Appendix E: SP2 POE Checkout Guidelines

Appendix F: Modifying a Samba Server to Work with VIP Applications

VIP 2003.4 Unix/Linux Release Notes Page 5

VIP 2003.4 Unix/Linux Release Notes Page 6

This release provides a wide range of enhancements, including the following

Desktop. The new JAVA-based Desktop has a Windows look-and-feel, with

Job Submittal. The new JAVA-based Job Submittal application with

Enhancements to VIP Data Studio. This efficient, wizard-driven application

Desktop-VIP 2003.4 Release Notes Page 7 Introduction

DESKTOP-VIP R2003.4 provides numerous enhanced simulation capabilities,

Enhanced Surface Pipeline Network, including optimization of well and

A basic implementation of injection networks in addition to production

Version independent restarts from R2003.4 forward. (A utility is provided to

Option for control of gas re-solution rate. (DRSDT)

Support for multiple water PVT regions, including optional property

Optimization of gaslift gas utilization at all targeting levels.

Threshold pressure option for fault flow.

Simultaneous bottomhole and tubinghead pressure constraints.

VIP Unix/Linux Users

Desktop-VIP 2003.4 Release Notes Page 8 Introduction

Minimum RAM: 256 Megabytes

Minimum Swap: 512 Megabytes

Minimum tmp: 512 Megabytes

Minimum Disk: 4 GB system/ 9GB user space

VIP 2003.4 Unix/Linux Release Notes Page 9 System Requirements

Sun Solaris Operating Systems

Additional Software Requirements

Additional Hardware Requirements

VIP 2003.4 Unix/Linux Release Notes Page 10 System Requirements

IBM AIX Operating Systems

Additional Software Requirements

Parallel Operating Environment (POE) 2.4

Parallel System Support Program (PSSP) 3.1.1

Additional Hardware Requirements

It is recommended that sufficient disk is added on each node to minimally provide

VIP 2003.4 Unix/Linux Release Notes Page 11 System Requirements

SGI IRIX Operating Systems

Unique Parallel Requirements

VIP 2003.4 Unix/Linux Release Notes Page 12 System Requirements

Linux Operating System

Unique Parallel Requirements

Distributed memory Linux workstation with two or more CPUs in a single

VIP 2003.4 Unix/Linux Release Notes Page 13 System Requirements

VIP 2003.4 Unix/Linux Release Notes Page 14 System Requirements

1. Version-independent restart files: The restart files have been restructured

Converting Restart Files:

Save and close the file.

Desktop-VIP 2003.4 Release Notes Page 15 Enhancements and New Features

rstconv <oldrestartfilename> <newrestartfilename>

3. Multiple water properties regions: Enables the user to specify different

1. Aquifer connections to LGRs: Enables aquifers to be connected to any