What You Actually Need to Know About the Eclipse 100 Manual
The Eclipse 100 Users Manual is two volumes that define how you set up a reservoir simulation run. It lists every keyword, every option, every validation rule the simulator checks before it will even start writing a restart file. Most people treat it as a reference they consult when a job fails. That approach works about half the time. The other half of the time you are staring at an ENDBOS or a keyword validation error that tells you nothing useful. I spent years debugging Eclipse decks that ran fine on someone else's machine and then failed on a different version, a different number of processors, or just a different operating system. The manual is not a linear read. You do not sit down and read it cover to cover. You learn which sections to open and which sections to ignore because they describe options you will never use in your workflow.
Schlumberger Eclipse 100 Users Manual
The document covers the complete input language. The DECK file structure, the SEQUENCER logic for time management, the MULTREGT keyword for region merging, the PATCH keyword for gridded data overrides, the PROPS section that defines relative permeability and capillary pressure tables, the SOLUTION section that sets how the Newton iterations behave. It also covers the output files. EXCEL, RSM, RESTART, and the binary files nobody understands unless they have actually tried to read one with a hex editor. Here is the thing most people miss. The manual does not explain why a keyword might be silently ignored. Eclipse has a validation layer that checks keyword combinations and throws errors for real problems. But it also has a layer that accepts keywords in certain contexts and discards them in others without saying a word. I once spent three days tracking down why my saturation dependent trap factors were not being applied. The manual does not mention it in the keyword description. It turns out you have to put the SDTRAP keyword in the PROPS section, not the SOLUTION section, and only when you are running the compositional option. I found the answer in an old Schlumberger support note, not in the manual itself. Another thing the manual presents cleanly but does not make obvious. The way Eclipse handles the JFUNC keyword. You can define multiple capillary pressure curves and the simulator selects between them based on the SATNUM and JNUM assignments in the GRID section. The manual shows the syntax. It does not warn you that if your JNUM values exceed the number of curves defined in JFUNC, the simulator will not error out. It will default to the first curve and silently corrupt your results. I had a model where the porosity-permeability transform created 48 rock types. The JFUNC table only had 20 curves because I was working from an older template. The simulation produced water saturation profiles that looked physically plausible. They were wrong. The fix was auditing every JNUM reference against the actual length of the JFUNC table, which is not something the Eclipse output highlights.
If you are setting up a new model, the first section of the manual you should read is the one on deck structure and the grid input. Eclipse grids come in several flavors. Cartesians, corner-point geometries, finite difference formats. The way you define the grid determines everything that follows. A malformed coordinate list will not necessarily crash the simulator. It might produce a cell with negative volume and the entire simulation will run with numerical diffusion that looks fine until you check the material balance. The manual is available through the Schlumberger documentation portal if you have an active license. There is no official public download link for the current version. Third-party sites sometimes host older copies, but those versions are often out of sync with the keyword changes in newer releases. Eclipse 100 went through significant updates between version 2005.3 and version 2011.1, and again with the 2014 and 2018 releases. If you are using a newer version and following an older manual, you will encounter keywords that no longer exist and missing descriptions for keywords that were added. Always verify the manual version matches your installed build number. It is printed on the first page of each volume. When I need to look something up quickly, I keep the manual open on one screen and the deck on the other. I search for the keyword I am questioning. The manual entry usually gives you the valid range, the default value, and the interaction notes. The interaction notes are the part people skip. They tell you whether a keyword requires another keyword to be present, whether it changes the behavior of an existing section, or whether it is incompatible with a particular physics option.
Get the Full Details
One practical tip that is worth mentioning. The Eclipse manual describes the TRACER keyword system in Volume 1, Section 7. It is easy to miss that the tracer module has its own separate input file, TRACER.DAT, which is processed before the main deck. If you put tracer definitions in the main DECK file, Eclipse will reject them. I learned this the hard way when a model ran perfectly until I tried to add a solubility model. The error message pointed to a missing keyword that did not exist anywhere in the main deck. The solution was moving the tracer data into the correct external file. There are limitations to what the manual can help you with. It describes the software, not reservoir engineering. It will tell you how to define a well constraint, but it will not tell you whether your planned injection rate is realistic for the permeability distribution you have modeled. It will validate your syntax, not your physics. If you are unsure whether a particular relative permeability curve makes sense, the manual is not the place to find that answer. You need to cross-reference it with core data or historical production. The manual is dense and deliberately so. It is written for engineers who already understand the fundamentals of reservoir simulation. If you are learning Eclipse from scratch, I would recommend working through a small tutorial model first. There are example decks included with the installation. Run them, modify them, break them intentionally to see what errors the simulator produces. Then go back to the manual and read the relevant sections with context. That approach cuts the time needed to become productive by roughly half compared to reading the manual before touching the software.
I have not found a better single reference for Eclipse 100 input syntax than the official manual. Third-party guides exist, but they are usually summaries that omit the edge cases. When something goes wrong and it is not a syntax error, the manual's keyword interaction notes and the validation section are usually where the answer lives. It takes patience to navigate, but the information is there if you know how to look for it.
