Petrel 2009.2 - Ocean - Schlumberger
Petrel 2009.2 - Ocean - Schlumberger
Petrel 2009.2 - Ocean - Schlumberger
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Schlumberger</strong> Public<br />
<strong>Petrel</strong> <strong>2009.2</strong><br />
Release Notes<br />
1
<strong>Schlumberger</strong> Public<br />
Copyright Notice<br />
Copyright 1998 - 2009 <strong>Schlumberger</strong>. All rights reserved.<br />
No part of this document may be reproduced, stored in a retrieval system, or translated in<br />
any form or by any means, electronic or mechanical, including photocopying and<br />
recording, without the prior written permission of <strong>Schlumberger</strong> Information Solutions,<br />
5599 San Felipe, Suite 100, Houston, TX 77056-2722.<br />
Disclaimer<br />
Use of this product is governed by the License Agreement. <strong>Schlumberger</strong> makes no warranties,<br />
express, implied, or statutory, with respect to the product described herein and disclaims<br />
without limitation any warranties of merchantability or fitness for a particular purpose.<br />
<strong>Schlumberger</strong> reserves the right to revise the information in this manual at any time without<br />
notice.<br />
Trademark Information<br />
*Mark of <strong>Schlumberger</strong>. Certain other products and product names are trademarks or<br />
registered trademarks of their respective companies or organizations .<br />
This software uses the FreeImage open source image library. See<br />
http://freeimage.sourceforge.net for details.<br />
FreeImage is used under the FreeImage Public License version 1.0.<br />
2
<strong>Schlumberger</strong> Public<br />
Contents<br />
<strong>Petrel</strong> <strong>2009.2</strong> ................................................................................................................................... 1<br />
Release Notes .............................................................................................................................. 1<br />
Copyright Notice .............................................................................................................................. 2<br />
Disclaimer ........................................................................................................................................ 2<br />
Trademark Information ................................................................................................................... 2<br />
What's new in <strong>Petrel</strong> <strong>2009.2</strong> ........................................................................................................... 4<br />
Software Download ......................................................................................................................... 5<br />
Geophysics ....................................................................................................................................... 6<br />
Geology ............................................................................................................................................ 6<br />
Geological Modeling ........................................................................................................................ 6<br />
Uncertainty & Optimization ............................................................................................................ 6<br />
<strong>Petrel</strong> Reservoir Engineering ........................................................................................................... 7<br />
Introduction ............................................................................................................................. 7<br />
Support for model initialization in Intersect ............................................................................... 8<br />
Results Tree Navigation Enhancements ...................................................................................... 9<br />
Development Strategy ............................................................................................................... 10<br />
Separator Definition .................................................................................................................. 13<br />
<strong>Petrel</strong> plug-ins for <strong>2009.2</strong> .............................................................................................................. 14<br />
<strong>Petrel</strong> Data in Context <strong>2009.2</strong> Plug-In ....................................................................................... 14<br />
OpenSpirit <strong>2009.2</strong> Plug-in.......................................................................................................... 14<br />
System Requirements.................................................................................................................... 15<br />
<strong>Petrel</strong> <strong>2009.2</strong> System Requirements ......................................................................................... 15<br />
<strong>Petrel</strong> <strong>2009.2</strong> Seismic Server System Requirements ................................................................. 15<br />
<strong>Ocean</strong> ............................................................................................................................................. 16<br />
Core and Geology – Known Issues ................................................................................................ 17<br />
Geophysics – Known Issues ........................................................................................................... 19<br />
Uncertainty and Optimization – Known Issues ............................................................................. 20<br />
Reservoir Engineering – Known Issues .......................................................................................... 22<br />
Core and Geology – Resolved Issues ............................................................................................. 24<br />
Geophysics – Resolved Issues ........................................................................................................ 26<br />
Reservoir Engineering – Resolved Issues ...................................................................................... 31<br />
<strong>Petrel</strong> - system crashes fixed by Microsoft hotfix. ........................................................................ 33<br />
3
<strong>Schlumberger</strong> Public<br />
What's new in <strong>Petrel</strong> <strong>2009.2</strong><br />
The <strong>2009.2</strong> release of <strong>Petrel</strong>* seismic-to-simulation software brings to the petrotechnical<br />
desktop a host of improvements that have been built upon the earlier 2009.1.1 release. Note<br />
that this is a major release - meaning that <strong>2009.2</strong> will install in parallel with any pre-<strong>2009.2</strong><br />
<strong>Petrel</strong> installations. Approximately 200 issues have been fixed in this release.<br />
After receiving many requests for full 64-bit support on XP 64, we are pleased to announce that<br />
this is now available with <strong>2009.2</strong>. <strong>Petrel</strong> now runs 64-bit on both Windows® Vista 64 and XP 64.<br />
Note that 32-bit compatibility mode on XP 64 is no longer supported.<br />
The OpenSpirit plug-in, created and owned by OpenSpirit Corporation, is ready for use with<br />
<strong>2009.2</strong>. See the OpenSpirit section for more details.<br />
The <strong>Petrel</strong> <strong>2009.2</strong> release will be delivered as a download only. Note also that the download will<br />
only be available through the SIS Support Portal to maintenance paying customers.<br />
(http://support.slb.com) For security reasons, the old completely public <strong>Petrel</strong> download site will<br />
now be closed. See the Software Download section for more details.<br />
Please note that any <strong>Petrel</strong> projects saved from <strong>2009.2</strong> are not backwards compatible - they<br />
cannot be opened with earlier releases of <strong>Petrel</strong>.<br />
4
<strong>Schlumberger</strong> Public<br />
Software Download<br />
The <strong>Petrel</strong> <strong>2009.2</strong> release will be available as an online software download only. There will be no<br />
hard media produced. A change in the download system has also been made - <strong>Petrel</strong> will no<br />
longer be available via a public internet download site; but will be available via the Support<br />
Portal to registered customers.<br />
A user account is required on this portal - if you do not have one, please visit the website and<br />
choose the option to Register. (As shown below)<br />
5
<strong>Schlumberger</strong> Public<br />
Check for software update<br />
When running <strong>Petrel</strong> 2009.1 or 2009.1.1, if you choose to run a Check for software update as<br />
shown below, you will be directed to the Support Portal login page. Enter your user credentials<br />
and, when successfully logged in, you will be able to download <strong>Petrel</strong> <strong>2009.2</strong>.<br />
Geophysics<br />
No new features in this release.<br />
Geology<br />
No new features in this release.<br />
Geological Modeling<br />
No new features in this release.<br />
Uncertainty & Optimization<br />
No new features in this release.<br />
6
<strong>Schlumberger</strong> Public<br />
<strong>Petrel</strong> Reservoir Engineering<br />
Introduction<br />
The purpose of the <strong>2009.2</strong> release of <strong>Petrel</strong> Reservoir Engineering is to support Intersect<br />
simulation workflows. Intersect is the <strong>Schlumberger</strong> next generation reservoir simulator<br />
constructed under an alliance program with Chevron. The first commercial release of Intersect<br />
(version 2010.1) is expected at the end of November 2009. A huge effort has been made to<br />
ensure that <strong>Petrel</strong> <strong>2009.2</strong> will be able to support Intersect 2010.1. However, as Intersect will still<br />
be undergoing beta testing when <strong>Petrel</strong> <strong>2009.2</strong> is commercial, there may be issues of<br />
incompatibilities arising at a later stage. Unless these issues are critical, we plan to resolve them<br />
in the <strong>Petrel</strong> 2010.1 version to be released early 2010.<br />
<strong>Petrel</strong> users will need to install a separate plug-in to enable Intersect workflows. The plug-in will<br />
be deployed with Intersect. The <strong>Petrel</strong>-Intersect plug-in will allow users to define and run<br />
Intersect simulation cases. The plug-in extends the Define Simulation Case process and provides<br />
access to the Intersect simulator through the simulator selection drop-down menu. Unlike<br />
ECLIPSE, Intersect does not use a keyword interface for model input. In place of the keyword<br />
editor, the <strong>Petrel</strong>-Intersect plug-in provides the Intersect Command Editor (IXCE) tool. IXCE<br />
provides access to Intersect features that are not available through the <strong>Petrel</strong> UI. Overall, the<br />
user experience conducting simulation workflows remains the same. Detailed description of the<br />
<strong>Petrel</strong>-Intersect plug-in, IXCE will be provided with the Intersect documentation.<br />
Several new developments and enhancements introduced in <strong>Petrel</strong> <strong>2009.2</strong> related to Intersect<br />
support are described below. Some of these enhancements can also be useful for ECLIPSE and<br />
FrontSim workflows.<br />
7
<strong>Schlumberger</strong> Public<br />
Support for model initialization in Intersect<br />
Intersect requires that the simulation grid and related properties (for example, cell-to-cell<br />
connections, transmissibility, pore volumes, etc.) are completely specified externally. This input<br />
is provided by <strong>Petrel</strong>, using the generic-simulation-grid (GSG) format.<br />
Grids with local grid refinements are processed to remove the global-local hierarchical<br />
relationship, non-neighbor connections across faults or with aquifers are processed and<br />
provided to Intersect. Equilibration information is provided to Intersect from <strong>Petrel</strong>. Likewise,<br />
3D simulation results need to be post-processed for visualization. All this is done automatically<br />
for the user by <strong>Petrel</strong>.<br />
Warning: Loading results (initial and recurrent grid properties) of an Intersect simulation into an<br />
existing project purely for the purpose of visual analysis is not supported. Therefore, it is advised<br />
to conduct the entire Intersect simulation workflow from within <strong>Petrel</strong> to avoid inconsistencies<br />
in results loading and visualization.<br />
8
<strong>Schlumberger</strong> Public<br />
Results Tree Navigation Enhancements<br />
A target workflow for Intersect is reservoirs with large number of wells. To improve the handling<br />
of large number of wells, saved searches and folder organization of wells in the Results tree has<br />
been implemented. The Results tree can be filtered and the active saved searches on the Input<br />
tree can be applied to the Results tree. The user can organize wells on the Results tree in a<br />
folder hierarchy as done on the Input tree. The actual organization is done on the Input tree and<br />
when applied, the Results tree inherits the folder structure and organization. <strong>Petrel</strong> will report<br />
any ambiguities if these exist.<br />
9
<strong>Schlumberger</strong> Public<br />
Development Strategy<br />
The Make Development Strategy now supports the Intersect simulator. Field management logic<br />
(well, group controls, constraints, etc.) in Intersect is handled by a distinct module called<br />
Intersect Field Management (FM).<br />
(1) Rules<br />
Several new rules have been introduced, while several existing rules have been made Intersect<br />
FM compatible. Some of the new rules are specific to Intersect FM. Note that some existing<br />
ECLIPSE/FrontSim rules are not supported by Intersect. By selecting the appropriate simulator,<br />
<strong>Petrel</strong> will filter down the list of available rules to reflect the simulator(s) selected.<br />
Historical Strategy Rules<br />
Intersect<br />
ECLIPSE<br />
10
<strong>Schlumberger</strong> Public<br />
Prediction Strategy Rules<br />
Intersect<br />
ECLIPSE<br />
11
<strong>Schlumberger</strong> Public<br />
(2) Rule Validation Enhancements.<br />
The logic used to validate rules containing parameters that are not supported by a specific<br />
simulator has been improved. A new rule state "Valid with Warnings" is provided. The icon and<br />
text for such a rule on the Strategy tree is colored blue.<br />
(3) Enhancements to Development Strategies UI<br />
Targeted drag/drop of wells/linked folders/well folders within and between well folders.<br />
Targeted drag/drop of wells within groups (i.e., the drag well is dropped immediately below the<br />
selected well). Targeted paste of wells/linked folders/well folders. Similar logic is applied to that<br />
for drag/drop as to exactly where the item is pasted. This targeting is also supported for the<br />
Replace functionality for well folders. Targeted addition of new wells/linked folders/well<br />
folders/groups to the strategy tree.<br />
12
<strong>Schlumberger</strong> Public<br />
Separator Definition<br />
Single- or multi-stage Separators can be defined using the new Separator modeling process in<br />
<strong>Petrel</strong>. When the separators are created, they stored on the Input tree. Separators can be<br />
imported as part of the fluid model or created when existing ECLIPSE simulation data decks are<br />
converted to a <strong>Petrel</strong> case. The imported separators can be edited using the Separator<br />
modeling process.<br />
The separators are associated with a field or region fluid-in-place separators from the Define<br />
simulation case process. Separators are associated with wells using the Development strategy<br />
process and the new Well separator rule.<br />
13
<strong>Schlumberger</strong> Public<br />
<strong>Petrel</strong> plug-ins for <strong>2009.2</strong><br />
<strong>Petrel</strong> Data in Context <strong>2009.2</strong> plug-in<br />
The Data in Context plug-in works with <strong>Petrel</strong> to provide the ability to quickly locate information<br />
using the search context (such as user profiles, project location, and objects) provided by <strong>Petrel</strong><br />
to retrieve the most relevant information pertinent to your project.<br />
Data in Context provides you with an instant view of all the relevant data within the context of<br />
your project area, within your geographical area of interest, and within the information with<br />
which you are working. By comparing the geographical and contextual proximity, you can<br />
quickly see new relevant data, and use it to make better and more informed decisions.<br />
You can refine your information search using the following features:<br />
• Spatial proximity—Enables you to search for data in a specific geographical area of<br />
interest.<br />
• Object context—Enables you to search for information based on the object context<br />
defined in a <strong>Petrel</strong> project.<br />
Once the relevant data is retrieved, you have several different viewing options in which to<br />
display the results, such as a map, a timeline, or a list.<br />
From the views available, you can select relevant data and save it for future use, or send it to E-<br />
Mail, KML (for use in Google Earth®), or Microsoft® Excel® spreadsheet.<br />
New Features <strong>Petrel</strong> Data in Context <strong>2009.2</strong> includes the functionality as <strong>Petrel</strong> Data in Context<br />
2009.1, but is compatible with <strong>Petrel</strong> <strong>2009.2</strong>.<br />
OpenSpirit <strong>2009.2</strong> Plug-in<br />
The new plug-in from OpenSpirit is currently in the closing stages of its commercialization cycle<br />
and will be available shortly for use with <strong>Petrel</strong> <strong>2009.2</strong>.<br />
<strong>Petrel</strong>'s existing OpenSpirit links will continue to function with this release. <strong>Petrel</strong> <strong>2009.2</strong> has<br />
been commercialized using OpenSpirit 3.1.4.<br />
14
<strong>Schlumberger</strong> Public<br />
System Requirements<br />
<strong>Petrel</strong> <strong>2009.2</strong> System Requirements<br />
This document outlines the hardware (HW) and operating system (OS) requirements for <strong>Petrel</strong><br />
<strong>2009.2</strong>. To ensure that <strong>Petrel</strong> functions and performs as expected, we are constantly testing the<br />
latest hardware available from major suppliers, as well as optimizing it for maximum<br />
performance. In our attempt to minimize unexpected problems and costs, we tend to use<br />
branded solutions, such as those offered by HP, Dell, AMD/ATI and nVidia. However, we do not<br />
exclude hardware from other vendors.<br />
<strong>Petrel</strong> <strong>2009.2</strong> Seismic Server System Requirements<br />
The <strong>Petrel</strong> Seismic Server is a cluster-based visualization, interpretation, and attribute analysis<br />
tool. It represents a cost-effective way for rapid prospect analysis and working with mega survey<br />
seismic over several hundred gigabytes in size. This document outlines the system requirements<br />
for the <strong>Petrel</strong> <strong>2009.2</strong> Seismic Server version. The Seismic Server admin utility and ZGY utility is<br />
not covered by this document. <strong>Petrel</strong> is the front-end application for accessing the Seismic<br />
Server. See the <strong>Petrel</strong> <strong>2009.2</strong> System requirements for details of the <strong>Petrel</strong> system needs. To<br />
ensure that the server functions and performs as expected, we are constantly testing the latest<br />
hardware available from major suppliers, as well as optimizing it for maximum performance. In<br />
our attempt to minimize unexpected problems and cost, we tend to use branded solutions, such<br />
as those offered by Sun, HP, IBM®. However, we also test on Hardware from smaller vendors<br />
such as Rackable Systems® and Vxtech.<br />
Please follow the link below to read the documents for <strong>Petrel</strong> <strong>2009.2</strong> System Requirements and<br />
Seismic Server System Requirements:<br />
http://support.slb.com<br />
Go to Product/Discipline -> <strong>Petrel</strong> -> Software Release Announcements<br />
15
<strong>Schlumberger</strong> Public<br />
<strong>Ocean</strong><br />
Reservoir Engineering<br />
UI extensibility for plug-in reservoir simulators<br />
Uncertainty workflow API<br />
Well segmentation, liners, keywords<br />
Data analysis / modeling<br />
Data selection filters<br />
Correlation & function data<br />
Variograms<br />
Seismic<br />
Seismic bulk order of magnitude speedup<br />
Multithreaded seismic bulk access<br />
Surface bulk order of magnitude speedup<br />
Fault & fracture patches<br />
Multi-input seismic attributes<br />
Other Domain API<br />
Reference project tool awareness<br />
Improved points, surface & well data attributes<br />
UI and look & feel<br />
Well-known tools and modes toolboxes<br />
Settings, import/export & data analysis dialog launch<br />
Keyboard events<br />
Improved explorer tree control<br />
Insensitive processes<br />
Workflow editor folders<br />
Asynchronous task manager<br />
Other<br />
64-bit native<br />
16
<strong>Schlumberger</strong> Public<br />
Core and Geology – Known Issues<br />
Issue ID Short Description Long Description<br />
2419077 Problems with graphics in Vista can<br />
occur if the Aero theme is switched<br />
on.<br />
Turn off Aero by: Open Appearance<br />
Settings by clicking the Start button,<br />
clicking Control Panel, clicking<br />
Appearance and Personalization, clicking<br />
Personalization, and then clicking<br />
Window Color and Appearance. If the<br />
Appearance Settings dialog box is not<br />
displayed, at the bottom of the page, click<br />
Open classic appearance properties. In<br />
the Color scheme list, select<br />
Windows Vista Basic, and then click OK.<br />
2404177 Visualization problems on Well<br />
Fence in 3D.<br />
3D visualization of Well Intersection<br />
Fence. Sections of a fence that should be<br />
behind the front section appear in front.<br />
2300152 Problems loading some SIF files. The problem occurs because some SIF/TIF<br />
files contain a second log curve panel in<br />
the file with the same MD ranges as the<br />
first. If there is just one panel, the file will<br />
be loaded correctly<br />
2420604 Rotated 2D grid/surface produces<br />
incorrect volume using volume<br />
below surface.<br />
2418401 Reference Project Tool does not<br />
transfer well names when moving<br />
well tops created in <strong>Petrel</strong> into a<br />
working project without wells.<br />
2421477 US Feet not recognized by<br />
Reference Project Tool.<br />
Volumes can be different when using<br />
volume below surface with rotated grids.<br />
Calculated volumes decrease with respect<br />
to true volumes as a function of the<br />
rotation angle, resulting in zero volume<br />
and area in highly rotated surfaces.<br />
When creating well tops, if the user is<br />
using RPT to move these into an empty<br />
project, the well tops in the new project<br />
will be unlinked to wells and will have<br />
incorrect well names under the Well filter<br />
such as "Well 1", "Well 2", etc. If the user<br />
imports well tops into <strong>Petrel</strong> and move<br />
them to the same empty project, the<br />
proper well names will be remembered<br />
even though they are also not linked to<br />
any wells.<br />
When using the RPT to move data from a<br />
reference project into a new working<br />
project, the RPT does not recognize units<br />
as being in “US feet.” However, if the units<br />
are set as “US feet” inside the reference<br />
project when the units and coordinate<br />
system are copied into the working<br />
project, the units come across as “feet.”<br />
17
<strong>Schlumberger</strong> Public<br />
2398139 Checkshot (velocity data) missing<br />
after copy of wells.<br />
2411075 Workflow Editor functionality to<br />
generate Truncated Lognormal<br />
distribution with Latin Hypercube<br />
sampling gives wrong output.<br />
2386132 Images rotated when displayed<br />
textured on a surface.<br />
If the user creates a subfolder under the<br />
Well folder and move some of the wells<br />
into this new folder and then use<br />
Ctrl+C and Ctrl+V to make a copy of the<br />
new sub folder. For any of the wells in the<br />
"Copy new sub folder,” there is no velocity<br />
data (checkshots, sonic logs, etc.) listed in<br />
the Settings/Time tab.<br />
Truncated Lognormal distribution with<br />
Latin Hypercube sampling in the<br />
uncertainty manager gives wrong output.<br />
The functionality works properly without<br />
Latin Hypercube sampling.<br />
When an image is displayed as textured<br />
over a surface, the image gets rotated to<br />
align on an N-S direction.<br />
18
<strong>Schlumberger</strong> Public<br />
Geophysics – Known Issues<br />
Issue ID Short Description Long Description<br />
2408726 Seismic Well Tie: Start time at top<br />
of sonic.<br />
Under the Datuming folder, the user can<br />
set the field for Two way travel time at the<br />
top of the sonic to blank. A blank field is<br />
not an allowed entry and can lead to<br />
wrong results.<br />
2357039 Velocity modeling: Border effects<br />
when generating an average<br />
velocity cube.<br />
2414417 Reference Project Tool - Transfer<br />
between projects with Coordinate<br />
Reference System created by<br />
OpenSpirit .<br />
The border effects are still present when<br />
generating an average velocity cube using<br />
the INC (user defined increment cubes)<br />
mode. The issue is fixed for cubes<br />
generated based on existing survey<br />
geometries (RES).<br />
The <strong>Petrel</strong> project CRS string created with<br />
OpenSpirit versions 2.9x are different from<br />
those created with OS 3.14 or later. Thus,<br />
it is possible to have two <strong>Petrel</strong> projects<br />
populated with data from the same OS<br />
source and have them seen by the RPT<br />
tool as having different CRS. This prevents<br />
data copy between the two projects. A<br />
work around is to set the project CRS<br />
created by OS 2.9x to NULL and then<br />
reconnect to the source via the 3.14<br />
version of OS and choose the CRS.<br />
19
<strong>Schlumberger</strong> Public<br />
Uncertainty and Optimization – Known Issues<br />
Issue ID Short Description Long Description<br />
2370052 Case collections limitations Case collections are not yet<br />
supported by the History match<br />
analysis process, Export dynamic<br />
result data and Make volumetric<br />
report. Workaround is to convert to<br />
folder of cases.<br />
2370229 Uncertainty and Optimization<br />
process: Automatic variable<br />
initialization not performed<br />
2258137 Uncertainty and Optimization<br />
process: Contact set used in Make<br />
fluid model process<br />
2346031 Uncertainty and Optimization<br />
process: Number of layers in scale<br />
up structure<br />
2351812 Uncertainty and Optimization<br />
process: Property calculator<br />
command detection<br />
2370230 Uncertainty and Optimization<br />
process: Variables not autodetected<br />
from well top calculator<br />
2370224<br />
Uncertainty and Optimization<br />
process: Orthogonal Array sampler<br />
in sensitivity analysis<br />
Initial values cannot always be<br />
determined automatically for<br />
variables in some processes. The<br />
user will have to enter the base case<br />
value manually in the variables tab.<br />
If variables have been introduced in<br />
the Make contact set process and<br />
the same contact set is being used in<br />
the, this task may fail. Workaround is<br />
Make fluid model to add contact<br />
variables in the Make fluid model<br />
directly.<br />
Setting No of layers in the Scale up<br />
structure process to a variable in an<br />
uncertainty workflow does not reset<br />
the grid to the state it was before the<br />
run. Therefore, it is recommended to<br />
make a copy of the grid before the<br />
run.<br />
When dropping in the base case, the<br />
system may not recognize all<br />
calculations that were previously<br />
applied to a property.<br />
When typing a $variable into the well<br />
top calculator, this variable is not<br />
detected by the system. The<br />
workaround is to define a user<br />
variable with the same name in the<br />
variables tab.<br />
The Orthogonal Array sampler<br />
should not be used in sensitivity<br />
tasks. By variable: Only one variable<br />
is active at a time, so Orthogonal<br />
Array Latin Hypercube is equivalent<br />
to normal LH sampling. By process: A<br />
different number of variables may be<br />
active at a time, so it is not possible<br />
to specify a valid number of runs.<br />
20
<strong>Schlumberger</strong> Public<br />
2354262 Uncertainty and Optimization<br />
process: Base case workflow update<br />
and performances<br />
2370228 Uncertainty and optimization<br />
process: Make fluid process not<br />
detected for imported fluid models<br />
Adding new steps to the workflow<br />
may impact on the execution<br />
performances, as all processes may<br />
then be automatically activated,<br />
even if not required. The<br />
workaround is for the user to change<br />
the command status to Disabled.<br />
If a simulation contains an imported<br />
fluid model, the make fluid process is<br />
not auto-discovered in the base case<br />
workflow. The workaround is for the<br />
user to drop in the Make fluid<br />
process manually.<br />
21
<strong>Schlumberger</strong> Public<br />
Reservoir Engineering – Known Issues<br />
Issue ID Short Description Long Description<br />
2356514 Applying 1-D streamline filters to 3-D<br />
properties with local grids.<br />
There is a known issue with applying a<br />
1-D filter created on a streamline to the<br />
display of a 3-D property in the 3-D<br />
window, when the case which<br />
generated the streamlines contained a<br />
local grid refinement. In this case <strong>Petrel</strong><br />
will not report an error and the filtered<br />
cells will be incorrect.<br />
2325247 Segment numbering – Well section<br />
window.<br />
The numbering of well segments as<br />
displayed and as exported could be<br />
different if the well path crosses<br />
inactive cells. When a simulation case is<br />
exported segments are uniquely<br />
defined so exported segment nodes are<br />
correct.<br />
2298250 Import of Schedule tubing file. Tubing imported from Schedule .TUB<br />
files that spans multiple wells is not<br />
imported correctly. Currently tubing<br />
ends at kickoff depth.<br />
2332101 Sector modeling with Local Grid<br />
Refinement.<br />
2370525 Fracture properties are not written<br />
when equal to matrix.<br />
Sector models created from <strong>Petrel</strong> with<br />
ECLIPSE 2009.1 or earlier that contain<br />
an LGR that crosses inactive cells (e.g.<br />
inactive layers or pinch outs) will report<br />
an error saying that the LGRs cannot be<br />
placed across the boundary. This is a<br />
known issue in ECLIPSE100 (Issue<br />
ID=2338600). Only ECLIPSE300 can<br />
handle this situation.<br />
When fracture array properties (grid<br />
tab and regions from the functions tab)<br />
are defaulted in <strong>Petrel</strong>, the user<br />
expects them to be the same as the<br />
matrix. However, <strong>Petrel</strong> does not write<br />
out the arrays for the fracture cells, and<br />
ECLIPSE does not copy them - it only<br />
does it for a limited set of GRID section<br />
properties, listed under the DPGRID<br />
keyword.<br />
2403814 LGRs in inactivated global grid cells. Under certain circumstances <strong>Petrel</strong><br />
exports LGRs for inactivated global grid<br />
cells leading to errors during<br />
simulation. A workaround is to load the<br />
PORV array processed by the simulator<br />
(INIT file) and use it to filter out inactive<br />
22
<strong>Schlumberger</strong> Public<br />
2419353 Loading simulation results - LGR<br />
properties<br />
2374748 Well stimulation data not correctly<br />
processed to skin.<br />
2414453,<br />
2420726<br />
Intersect workflow only: Cannot view<br />
or load PLT or RFT results into <strong>Petrel</strong>.<br />
2425685 Intersect workflow only: Numerical<br />
aquifer datum depth is exported with<br />
incorrect sign.<br />
cells and redo the 'Make local grids'<br />
process to update the LGRs. This is an<br />
issue in 2009.1 as well.<br />
Run time loading of LGR results will fail<br />
if the Define simulation case process<br />
window is closed by selecting the OK or<br />
if the Apply button is selected. The<br />
problem can be worked around by<br />
selecting the close window(X) button<br />
instead.<br />
<strong>Petrel</strong> uses the default open hole<br />
diameter on the global completions<br />
setting instead of the specified well<br />
diameter to compute skin for<br />
stimulation events. A possible<br />
workaround is to re-specify the open<br />
hole diameter to be the same as the<br />
perforation diameter if all the<br />
perforations are of equal diameter.<br />
<strong>Petrel</strong> is not converting the Intersect<br />
cell numbering correctly when<br />
importing the RFT/PLT results from an<br />
Intersect simulation run. The RFT/PLT<br />
results can be viewed using ECLIPSE<br />
Office.<br />
This issue does not affect ECLIPSE<br />
simulations.<br />
<strong>Petrel</strong> is not converting the datum<br />
depths for a numerical aquifer from the<br />
<strong>Petrel</strong> convention of negative depths<br />
below sea level to the Intersect<br />
convention of positive depths below<br />
sea level. The workaround is to specify<br />
the depth as positive for numerical<br />
aquifers that will be exported to<br />
Intersect.<br />
This issue does not affect ECLIPSE<br />
simulations; the datum depths entered<br />
in <strong>Petrel</strong> for aquifers exported to<br />
ECLIPSE/FrontSim should follow the<br />
<strong>Petrel</strong> sign convention; they will be<br />
correctly converted.<br />
23
<strong>Schlumberger</strong> Public<br />
Core and Geology – Resolved Issues<br />
Issue ID Short Description Long Description<br />
2404089 Displaying a k-layer higher than<br />
100 in a map window causes <strong>Petrel</strong><br />
instability.<br />
When displaying a property in a <strong>Petrel</strong><br />
window and then selecting a k-layer to<br />
view in the window (from the property<br />
settings); If the k-layer is higher than 100<br />
and the settings dialog is closed, <strong>Petrel</strong><br />
become unstable. If <strong>Petrel</strong> is closed<br />
down and the project is reopened,<br />
displaying a property in a map window<br />
will make <strong>Petrel</strong> unstable. Issue fixed in<br />
<strong>Petrel</strong> <strong>2009.2</strong>.<br />
2394207 Function window - crossplot of<br />
properties, raw logs filter still<br />
shows upscaled data.<br />
2398276 Deletion of many data points<br />
makes <strong>Petrel</strong> unstable.<br />
2401934 Saved Search automatically filters<br />
wells in Scale Up Well Logs<br />
2388084 Make horizons/zones - Poor<br />
results using Well adjustment in<br />
some cases.<br />
If you crossplot two 3D properties in the<br />
function window and activate the filter<br />
on the right side toolbar in order to look<br />
at the raw log data, you will see that the<br />
data is exactly the same as the upscaled<br />
data. Issue fixed in <strong>Petrel</strong> <strong>2009.2</strong>.<br />
Make/edit polygon - When deleting data<br />
points from a large point set, the<br />
memory allocation is increasing very<br />
quickly; <strong>Petrel</strong> will become unstable<br />
above 1.5 Gig. <strong>Petrel</strong> Tools/Free memory<br />
does not improve the situation. This is<br />
caused by the undo/redo function.<br />
Multiple undo was added on pointsets,<br />
prior to that there was only one undo.<br />
<strong>Petrel</strong> stores a full copy of the pointset<br />
for each undo operation. Large pointsets<br />
will take up a lot of memory. Issue<br />
resolved by limiting the undo function to<br />
20.<br />
When a Saved search is used, it<br />
automatically applies to the Well<br />
Selection list in Scale Up Well Logs.<br />
When All is selected, the only the wells<br />
included in the Saved Search are used for<br />
the Scale-Up process. Can cause<br />
incorrect results any time a Saved Search<br />
is left on. Issue fixed in <strong>Petrel</strong> <strong>2009.2</strong>.<br />
Wrong results obtained in Make<br />
horizons/zones process using "Well<br />
adjustment". The difference between<br />
the well tops and horizons were getting<br />
worse/bigger after well adjustment. This<br />
issue seems to occur only on some Pillar<br />
24
<strong>Schlumberger</strong> Public<br />
2397845 Reference Project Tool might be<br />
unstable when using spatial filter<br />
against reference project with<br />
checkshots.<br />
2394727 Error when pasting additional lines<br />
into deviation spreadsheet.<br />
2403133 Make log creates incomplete log<br />
along well.<br />
2370935 Minimum curvature interpolation<br />
gridding does not honor fault<br />
polygons.<br />
geometry, or steep horizons.<br />
When a background reference project is<br />
created from OpenWorks via OpenSpirit,<br />
it always sends the default checkshots<br />
for the wellbores. A standard practice to<br />
create user projects is to use the<br />
reference project tool and apply a spatial<br />
filter against the background project to<br />
filter the background project inside of an<br />
AOI, and then send this data to the<br />
working project. In 2009.1.1, when the<br />
background project has checkshots and<br />
the user applies a spatial filter against<br />
this project, the background project tree<br />
after filtering contains two well trees.<br />
The first with only the global logs as a<br />
child, and the second with all of the true<br />
wells as a child. When the user tries to<br />
perform a copy to their working project<br />
<strong>Petrel</strong> gets unstable. Issue fixed in <strong>Petrel</strong><br />
<strong>2009.2</strong>.<br />
When updating the deviation<br />
spreadsheet by first adding additional<br />
rows, then pasting from an Excel<br />
spreadsheet, <strong>Petrel</strong> either freeze or<br />
receive an error message as follows:<br />
“Md array is not increasing”. Issue fixed<br />
in <strong>Petrel</strong> <strong>2009.2</strong>.<br />
When moving a project with a 3D model<br />
with saturation from <strong>Petrel</strong> 2007 to<br />
2009.1.1 (32-bit); If you make a synthetic<br />
log in all wells of the project (and there<br />
are no logs in the project before creating<br />
the synthetic logs), <strong>Petrel</strong> makes the<br />
synthetic logs with "holes" along the well<br />
bore. This feature occurs mainly in<br />
horizontal wells. Issue fixed in <strong>Petrel</strong><br />
<strong>2009.2</strong>.<br />
Under Utilities->Make/Edit Surface, if<br />
you input horizon and a fault centerline,<br />
set geometry and select the algorithm:<br />
Minimum curvature interpolation, then<br />
the output surface does not honor the<br />
fault centerline. Issue fixed in <strong>Petrel</strong><br />
<strong>2009.2</strong>.<br />
25
<strong>Schlumberger</strong> Public<br />
Geophysics – Resolved Issues<br />
Issue ID Short Description Long Description<br />
2349288<br />
2349290<br />
2349298<br />
Annotation of seismic survey in 2D<br />
and 3D window.<br />
Various issues concerning the annotating<br />
of 3D seismic surveys have been addressed<br />
(font size, annotation direction,<br />
annotation visibility when viewing survey<br />
from the side).<br />
2351547<br />
2362908<br />
Neural network probability and<br />
principal component cubes output.<br />
When using classification neural network<br />
on seismic cubes, it is possible to create<br />
probability and principal component cubes<br />
as additional output<br />
2374009 Volume Attributes: <strong>Petrel</strong> freezes if<br />
volume attributes are created on<br />
seismic cubes with volume<br />
rendering on.<br />
2378414 Genetic Inversion: <strong>Petrel</strong> crash due<br />
to increased number of hidden<br />
layers.<br />
2373337 Virtual Cropped Volume: The OK<br />
button does not close the dialog in<br />
the settings dialog under the<br />
Cropping tab.<br />
2383879 The new color table slows down<br />
the turning on and off of data<br />
items in the tree when there are<br />
active (3D) window(s).<br />
2401837 Surface Attributes: Offset<br />
parameter for local loop surface<br />
attributes.<br />
Volume visualization style option for<br />
virtual cubes is not available anymore. This<br />
mode triggers a full cube calculation of the<br />
attribute, making the virtual attribute non<br />
performing.<br />
The user is now presented with a message<br />
"Number of weights in Neural Network too<br />
large compared to number of learning<br />
samples" and the number of hidden layers<br />
can be adjusted as required.<br />
Now working as expected.<br />
Fixed in <strong>Petrel</strong> <strong>2009.2</strong>.<br />
The horizon offset parameter for surface<br />
based loop attributes as set in the GUI was<br />
neglected. This has now been fixed.<br />
2392575 Memory fragmentation for 64-bit<br />
version when reloading project in<br />
the same <strong>Petrel</strong> session.<br />
The memory fragmentation is fixed.<br />
26
<strong>Schlumberger</strong> Public<br />
2398043 Seismic Interpretation corruption<br />
when project is saved on Samba<br />
mounted disk.<br />
Fixed. Note that this problem is only<br />
observed in certain version scenarios of<br />
Samba, network and operating system.<br />
2405900 Coordinate filter options. In the Project Settings dialog for<br />
Coordinate Systems, one can now also<br />
filter the list based on ESRI codes.<br />
2412045 Slow Reference Project transfer. Reference Project takes a long time to<br />
transfer data - message that it is<br />
computing derived data observed. This is<br />
resolved.<br />
2404704 Domain conversion fails when<br />
average velocity cube does not<br />
start at time=0<br />
Fixed. Now it is possible to have average<br />
velocity cubes, not starting at zero time, as<br />
input to the domain conversion process.<br />
2357039 Velocity modeling: Border effects<br />
when generating average velocity<br />
cube generation<br />
The border-effects problem is fixed for<br />
cubes generated as RES (picking up<br />
existing seismic geometries in the project).<br />
2370785<br />
2345940<br />
Velocity modeling: Problems when<br />
generating instant velocity cube.<br />
Issues with negative velocities and bulls<br />
eyes are resolved.<br />
2374496 Velocity modeling: Issues when<br />
generating average seismic velocity<br />
cube from velocity model when<br />
using welltop correction.<br />
2372339 Time logs and velocity logs are not<br />
properly generated when<br />
generated via the Output tab from<br />
"Create a velocity model" using an<br />
average velocity cube.<br />
2374496 Velocity logs not overwritten/<br />
updated when the velocity model<br />
is rerun.<br />
In certain scenarios, the average velocity<br />
extracted from the velocity model contains<br />
extreme negative and positive values. This<br />
problem is resolved.<br />
Logs are now properly generated when<br />
they are toggled on in the Output tab in<br />
the Velocity model dialog.<br />
Now, a rerun of the velocity model will<br />
update the velocity logs with the new data<br />
and update the visualization.<br />
2372834 Velocity modeling: problem with<br />
Vo-k from Well TDR-surfaces.<br />
In certain scenarios, when changing an<br />
existing Vo-k velocity model, a message<br />
"Cannot find enough TDR data in the<br />
zone..." prevents the model from building.<br />
In <strong>2009.2</strong> the model will build, omitting<br />
27
<strong>Schlumberger</strong> Public<br />
the boreholes which have out-of-range k-<br />
values.<br />
2415744 Velocity modeling: Spike effects at<br />
well locations when using (v0-k)<br />
constants and correction surface in<br />
the Velocity model.<br />
2384887<br />
2411151<br />
Geobodies: Wellprobes hard to<br />
manipulate.<br />
2396065 Geobodies: Thickness property<br />
miscalculated for seismic horizons.<br />
Problem first seen in <strong>Petrel</strong> 2009.1, but is<br />
now fixed.<br />
The wellprobe thickness manipulator is<br />
changed. To increase/decrease the probe<br />
thickness: Activate the probe manipulator<br />
tool. Press the ctrl key and click on the<br />
probe using the left mouse button. Hold<br />
the left mouse button down while moving<br />
up/down on screen.<br />
There was an issue with the scaling of the<br />
thickness property. Now the thickness<br />
property is properly calculated.<br />
2411420 Geobodies: Freeze when picking<br />
multiple geobodies on the same<br />
horizon probe.<br />
Issue resolved in <strong>Petrel</strong> <strong>2009.2</strong>.<br />
2402295 Geobodies: Units of the reported<br />
volume statistics not clear.<br />
Values are converted to and annotated<br />
with project specified volume and area<br />
units.<br />
2368436 Fault plane triangulation causes<br />
<strong>Petrel</strong> crash in certain scenarios.<br />
2398203 <strong>Ocean</strong> requires to set and get the<br />
seismic context associated with a<br />
fault polyline.<br />
Erroneous situations in the fault plane<br />
triangulation process are now captured<br />
and the user is presented with an error<br />
message window. The triangulation for<br />
this fault will be switched off.<br />
This is now implemented in both <strong>Petrel</strong><br />
and <strong>Ocean</strong>.<br />
2379166 Performance of Interpretation<br />
Manager.<br />
Interpretation Manager is now performing<br />
as expected for large number of<br />
interpretation objects (faults and<br />
horizons).<br />
28
<strong>Schlumberger</strong> Public<br />
2393432 Survey Manager performance. Various improvements to the survey<br />
manager are implemented (performance,<br />
changing filters, switching windows)<br />
2379354 <strong>Petrel</strong> crashed when trying to<br />
perform autotracking on a<br />
calculator cube.<br />
2396273 Seismic Interpretation corruption<br />
after "Save As" operation.<br />
Performing a 3D autotrack operation on a<br />
calculator or virtual attribute cube is<br />
deactivated and a warning message is<br />
generated. The calculator or virtual<br />
attribute cube has to be realized to allow<br />
3D autotracking activities<br />
Issue resolved in <strong>Petrel</strong> <strong>2009.2</strong><br />
2396488 Error accessing the statistics of a<br />
seismic horizon after using Save<br />
Project, followed by Free Memory.<br />
Horizon gets a black cross.<br />
2368211 Multithreading event prevents<br />
save project from Workflow<br />
Manager while process runs.<br />
An error message "Trying to retrieve data<br />
for Seismic horizon 1 on the file... Cannot<br />
read the format on the file" is presented,<br />
and the horizon gets a black cross. The<br />
workaround was to reopen the project.<br />
Now this issue is fixed and the problem<br />
will not appear anymore.<br />
While running a SaveProject in a workflow<br />
which has multithread calculations going<br />
on, the workflow will not be interrupted<br />
by error message pop-ups.<br />
2362225 Seismic Well Tie: Wavelets<br />
overwritten by the Reference<br />
Project Tool (RPT) do not get<br />
correct status in RPT dialog<br />
window.<br />
2366898 Seismic Well Tie: Different<br />
Calibrated Sonic values when<br />
transferred by Reference Project<br />
Tool (RPT).<br />
2384389 Seismic Well Tie: Crash caused by<br />
clicking Print in the New wavelet<br />
viewer.<br />
2400194 Seismic Well Tie: Start time at top<br />
of sonic.<br />
Overwritten wavelets, like overwritten<br />
LogSets, will now get the correct status in<br />
the RPT dialog window.<br />
A wrong unit handling of the Seismic<br />
Reference Datum (so for SRD0) in the<br />
Sonic Calibration process caused values of<br />
Calibrated Sonic to differ. This is now fixed<br />
by proper handling of the value/unit pair<br />
for the Seismic Reference Datum.<br />
A standard print dialog is added which<br />
allows the user to select a printer. If no<br />
printers are available, the Print button on<br />
the dialog will be inactive.<br />
Start time at top of the sonic log is added<br />
where there are no checkshot survey data<br />
available in the project<br />
29
<strong>Schlumberger</strong> Public<br />
2400195 Seismic Well Tie: Extracted wavelet<br />
in empty Wavelet Extraction<br />
window.<br />
A time shift issue was fixed for extracted<br />
wavelets that were dropped in an empty<br />
Wavelet Extraction window.<br />
2392571 Seismic Rendering in 3D window. Display gets striped appearance when<br />
zooming in on a displayed section from a<br />
ZGY cube in the 3D window. This issue is<br />
resolved.<br />
30
<strong>Schlumberger</strong> Public<br />
Reservoir Engineering – Resolved Issues<br />
Issue ID Short Description Long Description<br />
2385405 Export of LGRs in ECLIPSE keyword<br />
format<br />
Exporting a grid in keyword (.GRDECL)<br />
format using Models>Export>GRDECL in<br />
<strong>Petrel</strong> 2009.1 did not export the LGR<br />
keywords. This has been fixed in <strong>2009.2</strong><br />
2407428,<br />
2400642,<br />
2418648<br />
2205298,<br />
2386274<br />
2395794,<br />
2368933<br />
Coal Bed Methane Modeling Issues.<br />
Increased precision handling PVT<br />
properties to reduce simulator<br />
errors.<br />
Corrected export for simulation<br />
cases with multiple PVT and<br />
equilibration regions.<br />
2408553 Importing several PVT tables from a<br />
simulation keyword case/dataset.<br />
2411262 Loading production data using VOL<br />
file format<br />
2390240,<br />
2377858<br />
Problems with using historic<br />
(echoed observed) summary<br />
vectors.<br />
(a) The following ECLIPSE Coal Bed<br />
Methane option grid array keywords<br />
(COALNUM, GASCONC, GASSATC,<br />
MLANG, MLANGSLV, ROCKDEN) are now<br />
available for export on the Grids tab in<br />
the Define Simulation Case Process.<br />
(b) Fixed issues with extracting flux<br />
boundary conditions from CBM cases.<br />
a) Earlier very small values of oil-in-gas<br />
ratios (Rv) in input PVT tables were<br />
rounded off to zero essentially making a<br />
wet gas a dry gas and caused simulations<br />
to error. This has now been fixed.<br />
b) PVT properties export has been<br />
enhanced to avoid monotonicity errors<br />
caused by truncated numbers.<br />
<strong>Petrel</strong> was exporting PVT tables<br />
corresponding to equilibration regions<br />
(EQLNUM) and not PVT regions<br />
(PVTNUM) and setting the table<br />
dimensions (TABDIMS#2) to number of<br />
equilibrations regions. This has now been<br />
fixed.<br />
Earlier <strong>Petrel</strong> would load several PVT<br />
tables and sort them by name thus if<br />
more than 10 tables were imported table<br />
no. 10 actually became table no.2 and so<br />
on. This caused problems with matching<br />
PVT tables to imported regions. These<br />
issues are now fixed.<br />
<strong>Petrel</strong> was not consistently interpreting<br />
the *MISSING_VALUE when processing<br />
.VOL files. The problem is now fixed.<br />
a) There were issues with line plotting -<br />
accessing settings and display toggle, and<br />
b) and using these vectors in the dynamic<br />
data calculator. Issues have been fixed by<br />
not treating historic (echoed observed)<br />
vectors with a different identifies but as<br />
the same for other summary vectors.<br />
31
<strong>Schlumberger</strong> Public<br />
2417088 Output dynamic data to<br />
spreadsheet<br />
2400687 Creating aquifers caused <strong>Petrel</strong> to<br />
exit.<br />
2404423 Configuration error caused<br />
simulation launch error.<br />
2379893 Legacy ECLIPSE pre-post products<br />
launching.<br />
2389267,<br />
2422885<br />
Tensor upscaling issues.<br />
2378490 Segmenting wells with multi-level<br />
laterals.<br />
2406685 Consistent export of looped<br />
segments<br />
User defined Quantities (UDQs) can now<br />
be exported to an output sheet.<br />
Creating aquifers with top and bottom<br />
limits using contacts and surfaces caused<br />
<strong>Petrel</strong> to exit. This has now been fixed.<br />
Error in <strong>Petrel</strong> configuration files caused<br />
simulation launcher to fail.<br />
After a standard install EPP products<br />
(ECLIPSE Office, FloViz, Schedule, ...)<br />
failed to launch if the user did not have<br />
write access to the <strong>Petrel</strong> install<br />
directory. This problem is now fixed by<br />
using the particular <strong>Petrel</strong> project<br />
directory or a temp directory.<br />
a) Some weighting options relating to<br />
flow-based tensor upscaling were not<br />
correctly passed from the user interface<br />
to the upscaling algorithms, and tensor<br />
component selections were sometimes<br />
incorrectly reset after the upscale has<br />
been run. This resulted in incorrect<br />
results and an unsettling user experience<br />
when using these options. These issues<br />
are now fixed.<br />
b) The NTG and porosity weighting<br />
parameters were interchanged. Now<br />
fixed.<br />
Segmentation failed when a well had<br />
multi-level laterals, i.e. lateral kicked off<br />
from another lateral. This is now fixed.<br />
<strong>Petrel</strong> validation and export segment<br />
loops updated. ECLIPSE300 2009.1<br />
versions and later support loops.<br />
32
<strong>Schlumberger</strong> Public<br />
<strong>Petrel</strong> - system crashes fixed by Microsoft hotfix.<br />
Microsoft provides a hotfix that has proved to solve several issues with regards to XP<br />
32-bit system crashes when running <strong>Petrel</strong>.<br />
Several SMRs (2411716, 2346346, 2292952) regarding operation system crashes (blue screens),<br />
when working with <strong>Petrel</strong> (specific projects only), have been reported. These issues are all linked<br />
to XP 32-bit.<br />
The reason for why the system crashes is that Microsoft has a bug in the windows kernel. When<br />
we, in <strong>Petrel</strong>, draw filled triangles in 2D (property grids and smooth shaded contours on the Map<br />
window, seismic on the Interpretation window, properties on the Well section window etc.) it<br />
can corrupt kernel memory and take down windows. Vista 32/64, Windows Server 2003SP1, and<br />
Windows XP 64 bit ship with the fix. All earlier Microsoft OSs needs to be patched. The problem<br />
is not necessarily tied to screen drawing. For example, it may draw fine on the screen, but crash<br />
when printing, or if another application (for example, PowerPoint) reads an EMF containing<br />
triangles that were generated in <strong>Petrel</strong>.<br />
Microsoft has provided a hotfix, and after installing Windows XP-B912196-v2-x86-ENU.exe,<br />
which can be downloaded for free from the Microsoft web page<br />
(http://support.microsoft.com/kb/912196), all these issues were solved. No more blue screens<br />
to be seen.<br />
33