Coupling IMEX to FORGASs

IMEX can be linked directly to SPT Groups FORGAS surface network model.
IMEX and FORGAS each have their own input and output files. IMEX and FORGAS can have wells that
are shared or linked between the two. At the same time each model can have its own well(s) which are not
shared with the other model.
Before connections are made, the individual cases have to be modeled satisfactorily in their separate
application. Thus a IMEX data set must be able to run without the network model. All necessary sources
and sinks (wells) should be defined appropriately.
IMEX passes an IPR table (Inflow Performance Relationship - a table of bottom-hole flowing pressures
against phase rates) for each well to FORGAS.
The communication between the simulator and surface network model is made through signal and data
files that are in ASCII format. The simulator and the network model have their own signal and data files
which are automatically created and continuously updated by the coupled system. These files normally
reside in the directory where other input and output files are located and should not be deleted by the user
while the coupled system is running.

General Considerations and Guidelines

Connections between the reservoir and the surface network are made at well flowing bottomhole
conditions. Thus the network model must handle flow in the wellbore.
Some or all IMEX wells can be linked to the network model through the controlling interface (FORGAS).
IMEX generates IPR tables for those wells that are linked to the network model and in turn, gets
instructions from the controlling interface (FORGAS) on how to control those wells.
In general, IMEX wells linked to the network model have their operating constraints and schedules
described in the network model. On the other hand, wells within the IMEX model that are not linked to
network model have their operations controlled by IMEX.
IMEX can also be made to control certain aspects of a linked wells operating condition. Specifically for
linked wells:
1.
Any well monitor defined via the *MONITOR keyword is allowed.
2.
Keywords that control well and layer operations within a *TRIGGER are
allowed.
Details are given in the Recurrent data section of Preparation of IMEX data set section below.
Group production and injection controls (*GCONP,*GCONI, or *GCONM) are not permitted for groups
containing a mix of linked and unlinked wells. However, *GCONM could be exercised on groups
consisting of all the wells that are linked to the surface network.
IMEX is connected to the network model on a per well basis, using IPR curves.
There should be no IMEX well control keywords for network model linked wells besides the initial well
definition (see Preparation of IMEX Data Set).

Normally FORGAS controls the timestep the coupled model takes; however, IMEX can be made to
provide input to FORGAS about timestep selection. FORGAS will then select the minimum of the
network model and IMEX timesteps.
If the time to the next network model specified network solve date is too large, it is possible that a IMEX
wells bottom-hole pressure may vary considerably while timestepping to this date. Because IMEX no
longer controls its own well constraints for network model linked wells, a failsafe was implemented to
limit a wells minimum pressure to 101.325 kPa (14.7 psi). The use of this feature can be avoided by
reducing the network model maximum timestep size and/or by allowing the network model to use its own
adaptive timestep selector.
The IMEX start date defined in the recurrent data set should be equal to the network model forecast start
date. If the reservoir started production before the desired forecast start date, run IMEX alone to create a
restart record on the desired forecast start date. Use that restart record for the runs using the combined
models. A linked model may be started from a restart created by a linked or unlinked model. For instance,
a surface network linked model can run a prediction starting from the end of a reservoir history match
simulation.

Preparation of the IMEX Data Set

There are no keywords required for IMEX to couple with the network model. But as listed below, some
restrictions and changes apply.
The forecast start date of IMEX can not be earlier than the start date of the network model time schedule.
The IMEX start date can be a IMEX restart start date.

Recurrent Data
The following well data restrictions only apply to IMEX-Network model linked wells.
Well Definition
All IMEX-Network model linked wells should be defined once at the start time of recurrent data. No
further well keywords are necessary in the IMEX recurrent data after the start date. Wells which cycle
between injectors and producers should be defined as two wells in both the network and IMEX models.
Well SHUT/OPEN Status
IMEX passes open/shut-in status for linked wells to the surface network at each surface network date.
After receiving this well status information from IMEX, the surface network honors those wells IMEX
which shut in and may add other shut-in wells based on its schedule or optimization procedure.
The surface network then runs a new network timestep and passes the updated well status back to IMEX.
IMEX retains the received well status for the IMEX timesteps required to reach the new network date.
IMEX can attempt to open a well (using a monitor or a well control in a trigger), but if the surface
network schedule or its optimization overrides this, the well remains shut-in until the next network date,
where it will be checked again by the surface network, and if the network schedule or optimization allows
the well to open, it will open. This checking occurs at every surface network date.

So either IMEX or the surface network can shut-in a well. However, both IMEX and the surface network
must agree that a well should be open before it actually opens.
Well Constraints
For producers, a non-zero surface rate constraint should be given. For example,
*OPERATE *MAX *STO 500
indicates the target stream of the producer is oil and the specified rate is ignored. Similarly, non-zero
STG, STW, or STL can be used to indicate a gas, a water, or a liquid producer (if applicable) respectively.
If more than one of the STO, STG, STW, and STL constraints are defined, the first or primary phase will
be used to determine the IMEX constraint from the three phase rates received from surface network. If the
first or primary constraint happens to be other than a rate constraint, IMEX will use its internal logic to
determine the phase for which the well constraint would apply. Within the recurrent data, the keyword
*OPERATE with a non-zero rate can be used as the primary constraint to change the target stream phase
from one phase to another. The *OPERATE keyword for linked wells for phase change should normally
be placed within a trigger to avoid rate mismatch between IMEX and the surface network.
For injectors, the injection stream is given by the keyword *INCOMP.
Bottom-hole pressure constraints, if applicable, should be defined in the surface network. A BHP
constraint given in IMEX is ignored for rate calculation purposes. However, for injectors, if the keyword:
OPERATE *MAX *BHP 1000
is given, the value of 1000 will be used only to limit the maximum pressure of the IPR table. The
violation action *SHUTIN within the *OPERATE keyword should be avoided. For example,
*OPERATE *MIN *BHP 1000 *SHUTIN
for a producer may act at any IMEX timestep and cause rate mismatch between IMEX and the surface
network. Such conditional operations may be performed instead by the monitor or trigger keywords.
Injectors must be of the default mobility weighted type.
Monitors and Triggers
IMEX and the surface network ONLY exchange information at each network timestep. FORGAS
automatically uses ALL of the IMEX dates.
a)

Monitor
For well groups defined in IMEX, if a group contains all the wells as linked wells, the
applicable group monitor option is limited to the group monitor (GCONM) and the group
monitor will only be checked at surface network dates. On the other hand, if a group does
not include linked wells, group monitors can be applied as usual. An error status occurs
when a group contains a mix of both linked and unlinked wells.

b)

Trigger
Keywords that directly change the well status or that modify productivity for linked wells
(i.e. not in triggers) should be avoided. For example, if well 2 is a linked well and the

date 2000 1 1 is not a surface-network date. The inputs,

*DATE 2000 01 01
*SHUTIN 2
will shut in well 2 between two surface network dates, but cause a rate mismatch between
IMEX and the surface network. This inconsistency should be avoided by using triggers as
discussed below.
Triggers are the means by which the user can ensure that well controls are only applied
when IMEX and FORGAS are synchronized. The user must place all well control
keywords within triggers because in linked runs only trigger keywords checked at surface
network dates.
In the example below we redefine the layers for well no. 2, then multiply its original
productivity index by five at the first surface network DATE after 2000 1 1
*DATE 2000 1 1
*TRIGGER 'trg_well2' *ON_ELAPSED 'TIME' treltd > 0.0
*GEOMETRY *K 0.07 0.37 1.0 0.0
*PERFV *GEO 2
** KF FF
2:3 1.0
*SETPI *MULTO 2
5.0
*END_TRIGGER
The use of the *ON_ELAPSED TIME treltd > 0.0 trigger would normally force the
trigger to fire immediately, but as this is a linked model, the trigger is checked at the next
surface network date.
Keywords *OPEN and *SHUTIN for wells should be included in triggers. For example,
*DATE 2000 1 1
*TRIGGER 'shut 2' *ON_ELAPSED 'TIME' treltd > 0.0
*SHUTIN 'PRODUCER-2'
*END_TRIGGER
Of course triggers can still be used to control when a well is shut in based on a real
criteria, such as in the example below, where a well is shut in when its well bottom-hole
pressure is less than 1000 psia.
*TRIGGER 'trg_bhp2' *ON_WELL 'PRODUCER-2' BHP < 1000.0
*SHUTIN 'PRODUCER-2'
*END_TRIGGER
The trigger above will be executed at the surface network date when the bottom-hole
pressure of PRODUCER-2 is lower than 1000 psia.
IMEX does not exchange well layer status information with the surface network.
However, similar to well status, changes for well layer status should be specified only on
surface network dates.

It is important to note that for a IMEX run coupled with surface network, trigger action
will occur only at a surface network date irrespective of whether the well in question is
linked or unlinked.
ON-TIME Fraction
For linked wells, at each time step, the FORGAS down-time percentage is passed to IMEX as an on-time
fraction. IMEX uses the received on-time fraction as if the same value was input through the IMEX
recurrent data. Essentially the definition/handling of on-time fraction for coupled wells is moved to the
FORGAS network.
For unlinked wells, on-time fraction should be given in IMEX recurrent data as usual.
IMEX passes back on-time fraction for all wells to FORGAS.
DATE and TIME
*DATE and *TIME keywords can normally be used within the IMEX data set. These can be used to
obtain IMEX output when the *WPRN/*WSRF output options are used.
The forecast start date of IMEX must be the same as the forecast start date of the surface network date
schedule. Use a restart record to adjust the IMEX forecast start date to correspond to that of the surface
network model.
FORGAS will honor the IMEX stop date; the earliest stop date (between that specified in FORGAS and
that specified in IMEX) will be used.

Multiple Reservoirs
..

The surface network model can connect to multiple IMEX reservoir models. FORGAS
requires all IMEX files to have same start date.

..

IMEX and the network programs communicate through ASCII files. Four ASCII files per
IMEX instance are created and updated during the linked run. The files are named using
the root IMEX input data file name and the extension related to their use within the
linked model (LSResolve, LDResolve, LSIMEX, and LDIMEX). These files must not be
altered by the user during a linked model run.

Remote Simulation Job Submission via SSH

The IMEX-FORGAS link is designed to optionally submit simulation jobs to network computers via
Secure SHELL (SSH). Here the network refers to the intranet/LAN. The required environment
requirements for remote submission are:
a)

The targeted remote computer should be a SSH server (running SSH service) and the local
computer should have a SSH client program installed. The SSH client issues a ssh command to
execute the simulation on a SSH server.

b)

Both local and remote computers should be able to create/read/write files in the folder/directory

where the simulation dataset exists. IMEX and FORGAS exchange data in that work folder.
SSH Server
Linux and IBM AIX computers are equipped with OpenSSH which provides SSH Daemon (SSHD) as the
SSH service.
Windows computers needs to install a third party software to run an SSH service. For all our tests,
WinSSHD (http://www.bitvise.com/) was used to provide the SSH service for Windows. Tested Windows
platform were Windows Server 2000, Server 2003 and XP 64 bit.
SSH Client
The SSH client must be on Windows, because the local machine needs to run FGI for the FORGAS link,
a Windows based program. There are quite a few software vendors who provide SSH clients for Windows
at a low cost. We developed/tested using CopSSH (http://www.itefix.no/phpws/index.php ) which is an
OpenSSH derived Windows version. The client program has been tested on Windows 2000, XP, XP 64 bit
and Vista.
Note: After the installation of CopSSH, the user may need to edit the Windows environment variable
path to add the SSH bin directory in the path, e.g.: C:\Program Files\copSSH\bin.
SSH Settings
There are various approaches that can be used to enable SSH communication. The following description
is intended to give an example of one such approach that was employed in our testing process. For
technical details, please refer to the SSH software manual.
The ultimate object of the SSH settings is to allow the user to invoke remote simulation by issuing a one
line ssh command at a local command console. For example, the following command line should
directly start the IMEX with the dataset, dataset1.dat,
ssh l username_on_server simsvr d:\cmgexe\IMEX.exe f d:\cmgdata\dataset1.dat

where the simsvr is a remote Windows computer.

In order to do so, the remote computer (SSH server) should be set so as to accept the user login without
password. Instead of password authentication, SSH client and server, by default, use key authentication to
establish connection.
Generating Key Pair
The user can use ssh-keygen.exe available with CopSSH to generate a private/public key pair. Using sshkeygen.exe, two key files, viz., id_rsa and id_rsapub, should be generated into the folder .ssh, which is
created under the users local Windows home directory. A blank passphrase is suggested when doing
key pair generation. If the key pair is made with a nonblank passphrase, the passphrase will be asked for
each time SSH attempts to login.
Registering Public Key in the Sever
For the UNIX/OpenSSH system, the user needs to copy the public key (e.g. from file id_rsapub) and

append it into the file: $HOME/.ssh/authorized_keys.

For the Windows/WinSSHD system, the system administrator needs to start the WinSSHD Control
Panel/ Settings, and in the Access Control/Windows accounts tree view add the user and then import
the users public key.
For the first time to configure the installed WinSSHD, system administrator also needs to register the
network domain name. That is, under the same Settings tree view, choose the Domain order and click
the Add button to add the domain name.
Test SSH
After the above steps are done, the user can test SSH by trying a ssh command from the local command
console, such as:
ssh simsvr set

If the above command gives out the user environment variables in simsvr, SSH has been successfully
set up. This command assumes the users login name is the same on both the server and the local
computer.
Please note that the first time a user tries to link to the SSH server, SSH will respond that it can not
establish authenticity and will query if the user wants to continue. A yes response is necessary to allow
SSH to import the host key, i.e. the servers public key, to the client side.
Settings in Linux/AIX for the CMG Simulator Environment
In order to make sure the SSH login reads the UNIX shell startup file ( .cshrc, .kshrc, etc.) which includes
the values for CMG_HOME, LSFORCEHOST and LD_LIBRARY_PATH, the following should be done in the
OpenSSH server:
a)

In users $HOME/.ssh directory, create a file with name environment. Add one line,
ENV=.kshrc, into the file (assuming Kshell is used).

b)

Make sure /etc/ssh/sshd_config file contains the next line:

PermitUserEnvironment yes

SSHD needs to be restarted to ensure the updated sshd_config file is read.

These settings ensure the $HOME/.kshrc is read when SSH logs in.
If the $HOME is a shared directory among UNIX machines and those hosts need different CMG variable
settings, the shell startup file can include a case command to account for different hosts. For example,
simsvr|simsvr1)
LD_LIBRARY_PATH=/usr/cmg/IMEX/Linux_x64/lib:\
/opt/intel/fce/9.1.036/lib;LSFORCEHOST=lserv;export\
LD_LIBRARY_PATHLSFORCEHOST;;
aixsvr|aixsvr1)LSFORCEHOST=lserv;exportLSFORCEHOST;;
esac

Location of the working folder

It is recommended to have the working folder on the local disk of the machine on which the simulation
runs. This simplifies file access and reduces traffic through the network thus providing a better response
between IMEX and FORGAS. However, the working folder can also be created on a disk controlled by a
third file server, if desired.
A Local path to work folder is required in the CMG case setting window, which tells FORGAS how to
access to the working folder. In the entry, the path should be addressed simply and directly. A path across
multiple machines/mount points should be avoided.
Known Problems and Workaround
Samba Server
If the work folder/directory is located on a drive under a UNIX platform, and the user notices an
unreasonable delay or even a hanging up on alternating text file communication between IMEX and
FORGAS, there can be file sharing problems caused by Samba opportunistic file locking. The
workaround is to switch off the file locking for all IMEX/FORGAS communication files. That is, in the
Samba configuration file (e.g. /etc/samba/smb.conf), add a line for the share where the work folder is
located:
vetooplockfiles=\
/*.LSImex/*.LSResolve/*.LSIMEX/*.LDImex/*.LDResolve/*.LDIMEX/

And restart the Samba daemon to make sure the altered smb.conf is used.
Linux Simulator Execution with Work Folder on a Windows PC (using Samba Client)
When a job is submitted to a Linux platform and the working folder is located on a Windows PC, IMEX
and FORGAS may lose communication due to Windows file locking. If this occurs, the user needs to
check how the Local path to work folder is defined. If the path does not start with the server-name of
the Linux platform, the user must alter the server-name to the Linux platform name (e.g.
\\Linux_CPU\...).

Coupling with FORGAS

The FORGAS calculation engine facilitates exchange of signal and data between IMEX and FORGAS in
addition to performing various other functionalities required for the running of the network model. The
user provides the name of the IMEX input file as well as the name and location of the IMEX executable
in the FORGAS data preparation program, FGI. In the FORGAS input data file, shared FORGAS/IMEX
wells should belong to a IMEX reservoir. For each IMEX reservoir defined in FORGAS, the user
selects the name of the IMEX input data file and an optional index-results file (irf).
When the user selects to Run FORGAS inside the FORGAS interface, the coupled system will perform
the following steps.
1.

FORGAS will automatically start the specified IMEX executable using the file names of the
specified IMEX input data files. The IMEX log file will appear within a DOS window, which the
user can view as the run progresses.

2.

FORGAS will wait while IMEX initializes its calculations and provides the inflow performance
data to FORGAS for each well defined in IMEX.

IMEX will pass its current date. If this date is earlier than the forecast start date in FORGAS,
FORGAS will end the forecast with an error message. IMEX will recommend the length for the
next timestep (in days). FORGAS will ensure that the first FORGAS timestep will be exactly one
day in length, by providing the appropriate timestep information to IMEX. Thereafter, the
recommended timestep from IMEX will be used, unless it needs to be shortened by FORGAS for
user specified changes in the FORGAS input data. The minimum timestep in FORGAS is one
day. If the timestep recommended by FORGAS is too long for IMEX, IMEX will take as many
timesteps as required to move forward the required number of days. When there are multiple
IMEX input data files coupled to FORGAS, FORGAS will look at the recommended timestep
from each IMEX file, and will use the smallest of each to determine the next timestep to take.
FORGAS will pass that timestep length to each IMEX file. Repeating FORGAS timesteps is not
supported.

4.

After the initialization phase, IMEX will wait until FORGAS has finished the calculations for the
first timestep. For production and injection wells, FORGAS provides the oil, water and gas flow
rates at the set point which are interpolated from the IMEX IPR tables. For each shared well, the
well status (OPEN or SHUTIN) is passed by FORGAS to IMEX. The flowing bottom-hole
temperature will also be provided to IMEX. For production wells, this temperature will be equal
to the reservoir temperature. For injection wells, this temperature could be different than the
reservoir temperature when temperature is computed in the wellbore. The next FORGAS timestep
length (in days) is also provided.

6.

Once FORGAS has finished its first timestep, it now waits for IMEX to use the data provided by
FORGAS to calculate the conditions at the start of the next FORGAS timestep. IMEX now reads
the data provided by FORGAS to determine which of its wells are shared with FORGAS. IMEX
performs its timestep(s) to reach the specified FORGAS timestep. IMEX calculates the inflow
performance of each well and passes that to FORGAS. The current date and the recommended
length of the next timestep are passed to FORGAS. Then IMEX waits until FORGAS has
retrieved and used the data to determine the well flow rates for the next timestep.

7.

The forecast will continue until the end date is reached (namely the earliest date of those
specified in the FORGAS and IMEX input data files) or there is an error encountered by
FORGAS or IMEX.