GêBR User's Guide

The GêBR Project was initially proposed to develop and promote the GêBR interface. During 2007–2008, the core team of developers had offered several courses on seismic processing with GêBR, at the most active research centers in Geophysics in Brazil. Around 200 students and professionals had direct contact with the project on that period. In that process the GêBR observed a demand for integration efforts among Brazilian geophysical community. That motivated a redefinition for the project’s goals.

For more information, visit the project's official site: http://www.gebrproject.com.

This user guide is for GêBR version 0.20.0. The images in this guide were captured in a Ubuntu 10.04 based system. Therefore, slight differences may be observed in case another operating system is being used. For specific installation instructions for each operating system, see the install guide, in the project's official site.

Director:

Developer manager:

Developers:

Consultants:

Former members:

Thank you for using GêBR!

GêBR is primarily conceived to process 2D seismic data lines. Data from 2D acquisition lines related somehow are usually grouped in one seismic-data processing project. The processing of a specific data is carried out by a bunch of processing flows. Each processing flow is a chain of programs, which sequentially operate on an input data to produce an output data from it. For example, processing flows can be assembled to accomplish tasks like Spike Deconvolution, Noise Atenuation, NMO correction, and so on.

In GêBR, a seismic-data processing project is referenced as a project only. Each project can hold many seismic data, each one referenced as a line. Each line has its own set of processing flows or just flows for short.

In summary, GêBR has three levels organization, from top to bottom:

Thus, before creating and executing flows, it's necessary to create at least one project owning one line. Section 3.1, “Creating projects and lines”, and Section 4.2, “Creating flows” explain how this is accomplished.

To assemble a flow, the user has not only to select programs, but also configure them properly, through their parameters. Once the flow is configured, it is ready to actually be executed.

A flow is a sequence of programs, as just explained. In GêBR, the user might think that there is a list of available programs to assemble flows. This is partially true only. Indeed, flows are built from menus. But what is a menu?

A menu is a representation of a single program or a set of programs. This means that when a menu is added to a flow one or more programs will be inserted into the flow at once. Why is that so? Think about common tasks that are accomplished by a standard sequence of programs. Instead of building a flow by adding programs one by one, the flow could be built from a menu, which packs the whole set of programs. For example, consider the task of adding header to a raw data to come up with a seismic data in Seismic Un*x format. Figure 2.1, “Add header flows” shows two possibilities to assemble the same flow, depending on how the programs SU Add Header and SU Set Header are represented, either as two independent menus or as one menu encapsulating both programs.

Figure 2.1. Add header flows

A common flow to add header to a raw data is built by sequencing SU Add Header and SU Set Header. The top image represents the flow built from two menus, one for SU Add Header and another for SU Set Header. The bottom one represents the same flow, but built from only one menu, that encapsulates both programs.

After assembling the flow, to complete its set up, the user has to inspect each program of the flow and define its parameters. Programs may depend on many parameters, from a variety of types. GêBR supports parameters of the following types:

The GêBR set of tools is composed by two main player categories: GêBR (the interface itself) and nodes.

The GêBR interface, sometimes referred as GêBR only, is the graphical interface with whom the user interacts to build flows, execute them, inspect results, etc. Usually, this interface is installed and is running in the machine the user has physical contact with.

The user may have access to many machines, which is an usual scenario for users of a computational laboratory. Through GêBR, it is possible to take advantage of these machines. A machine used to run processing flows is called a processing node, or just node, for short. They may be local, meaning the user is physically using them, or remote, meaning the user has access to them through the network. No matter where the machines are, they are equally treated by GêBR, which means that the user does not have to care about that.

Whenever machines can cooperate to run processing flows, they are grouped into domains. Basically a domain is a set of processing nodes that have access to the same files in disk, and therefore can operate on the same data sets.

GêBR does not talk directly to each node of a domain. Instead, it elects one processing node of the domain to be responsible to receive all requests from the interface and redistribute them to the processing nodes. This special node is called maestro. Any node can assume this function.

Figure 2.2. Communication layout between GêBR players

All communitation between GêBR and the nodes are intermediated by the maestro.

In case the machine acting as the maestro fails or is no longer accessible to the GêBR interface, another processing node assumes this function.

Figure 2.3. Another node assumes the maestro position whenever necessary

When the user decides to execute a flow, GêBR sends the request to the maestro, giving rise to a job. The maestro acts as a coordinator of the nodes into the domain, collecting information and ranking them according to their capabilities and available resources. Therefore, the maestro can take smart decisions about which machines are best suited to run a job.

The nodes put their computational power at disposal of the maestro. Under maestro's coordination the nodes can even cooperate to conclude processing jobs fasters.

The maestro receives the job submission and dispatches the job to some of the nodes under its control. All the information generated by the job is collected and sent back to GêBR, where they are presented to the user.

This communication process, despite complex, is completely transparent to the user, which can concentrate on processing seismic data, leaving all technical details to GêBR.

The GêBR interface is intentionally simple. It is organized in three tabs:

There are also additional resources in menu bar, on the top of the window:

The button creates a project. The title and description of the project, besides user's email are asked during this action. This basic information can be further edited through the edit button .

The project will appear on the left side of the window (see Figure 3.1, “Projects and Lines tab”). Information about the project is shown on the right hand side of GêBR's main window. Note that some of this information comes from what was previously specified. Details such as creation date and modified date are automatically generated by GêBR.

The button creates a line. The information below will be requested to complete this operation:

An assistant dialog will guide the user through the setup of a line. When the assistant is completed, the line will be created and shown as part of the selected project. Like the project's settings, the line's settings are exhibited on the right side of GêBR's window.

To create lines, GêBR must be connected to a domain (see Section 2.3, “GêBR players”). This is mandatory since the all paths created at that moment should be in the file system of the processing nodes of a connected domain.

To delete a line, select it and then left-click on . A dialog will pop up to confirm this operation. A checkbox in that dialog allows the user to instruct the GêBR to delete all files in the BASE path of the line.

To delete a project, it must not contain lines, so it is necessary to delete them first, and then proceed to the project. This is a protection to avoid miss-clicking the delete button.

GêBR defines a directory structure to aid in the task of managing the data associated to a set of flows. This structure is defined by a top directory, known as BASE, and few other nested standard directories. They are:

Other important folder is the HOME, which is is automatically set to the path of the user's home directory.

For instance, suppose we are going to set the important folders of a line. If the user's home folder is /home/john/, the BASE path must be set inside /home/john/. Taking this into consideration, and setting the BASE path to /home/john/GeBR/MyFirstLine/, this is going to be the directory structure associated to the line:

This standard directory structure eases the task of managing data related to lines (see Section 4.5, “Editing the flow's input and output files”).

GêBR supports only one connected domain at once. However, there may be several domains available, one domain for Lab A and another for Lab B, for example.

Whenever GêBR is connected to one specific domain, all lines belonging to other domains won't be available for edition. However, a line can be migrated from its original domain to the connected domain. To do so, the line must be selected. In the right-hand side panel, an icon in the upper left corner indicates whether the domain of the line is connected or not. In case the original domain is not connected, by clicking on that icon, GêBR will offer two options:

Figure 3.2. Dialog for lines from domain with disconnected domain

Options available when it is desired to edit/run a line associated to a disconnected domain.

Although GêBR continuously saves all data, sometimes it is desirable to have copies of projects and/or lines in a file (for example, to share them with others or to make backups). To export a project or a line:

To import projects or lines that were previously exported follow the steps:

An imported project is added to the list of projects, while an imported line joins the other lines of project that was selected prior to this process. In both cases the imported item is identified with the suffix Imported.

Projects and lines can be commented. The commentaries are free formatted text. While for projects the report is entirely composed only byt the user's commentaries, for lines, the report is created automatically, including not only the user's commentaries, but also information about its flows.

To edit the commentaries of the project or line, follow the steps:

Figure 3.3. Built-in commentary editor

The comment editor window.

The report can be visualized by clicking on More → View Report.

Figure 3.4. View Report

The line report contains information concerning the associated flows and their programs, important folders and variables.

After clicking on View Report, a window will appear showing the report for the project or line. In the case of line's report, some customization options are available:

Figure 3.5. Report menu

GêBR enables the report customization.

In Section 2.2, “Menus, programs and their parameters” a menu was defined as a set of one or more programs that can process data. These menus are accessible in the Flows tab, trough the button menu list presented in the toolbar.

After clicking the menu list button, a pop-up window is shown with a list of categories. All menus registered inside GêBR are classified into these categories, which can be expanded by clicking the icon on the left.

By typing parts of the menu title or description in the text box on the top, it is possible to filter the menus list. This eases the task of finding or discovering a menu when its purpose is known. For example, it is possible to search for menus related to migration (see Figure 4.2, “Filtering the menus list”).

Figure 4.2. Filtering the menus list

The image shows the menus list being filtered by migration. All menus that have the word migration in its title or description are shown.

In the Flows tab, the button creates a flow. Title, description and flow's author should be provided in the creation, and can be further edited through the button .

After following these steps, the flow will appear on the left side of the main window. The right side will show information about the flow.

A processing flow is a sequence of operations defined by the user. These operations, also called programs, are organized into the following categories according to their purpose:

After the flow is created, a pop-up appears with the available menus and is possible assemble the flow:

The flow is ready to be executed. Click on or on to do it (for more information, consult Section 4.7, “Executing flows”).

After the flow has been assembled, it will be visible on the left side of the main window when the Flows tab is selected. The Details box, found on the upper right side of the main window, shows information about the selected flow. The Flow Review box shows a brief of the flow and contains information like input, output and log file, flow's programs and some of its parameters.

Programs can be in two states only, Enabled () or Disabled (). If a program is enabled with an error, the icon changes to .

Alternate between these states by using two methods: right-clicking on the program and then select the desired state from the context menu or using the shortcut Spacebar to change the states of the selected programs. It's possible to select several programs whose state is desired to change by holding Ctrl+Click or Shift+Click.

Program's parameters compose a set of initial configurations defined by the user.

To edit program's parameters follow the steps below:

In many occasions, it's necessary to extract data from an input file and/or generate as a result an output file, or even an log file in case an error occurs.

To associate an input, output and error file to a flow, follow these steps:

Figure 4.3. Input file setting

Select the Flow Editor Tab. In the Flow Sequence box it's possible to edit the input, output and log files for this flow sequence.

For using the folders associated to the line, choose them like above or use the feature of autocomplete of the important folders of this line. For more information, see Section 3.3, “Important folders of a line”.

Figure 4.4. Autocomplete of paths

Autocomplete feature in the Input file of a flow. Analogous to the dictionary variables, to see the available paths it is just necessary to type a <.

When a path is chosen for the flow's input/output, their file paths will appear in entries, indicated by the icons and , below and above the flow's programs (if there are any).

The clipboard provides the popular set of tools known as copy and paste. A flow (or set of flows) can be copied to the clipboard and paste back to the same line or to other lines. In the same manner, a program (or set of programs) can be copied to the clipboard too, and can be paste to the same flow or to other flows.

To copy flows or programs to the clipboard, first select them with the mouse, and then use the button or press the usual shortcut Ctrl+C. After copying the user can paste it by clicking on the button or by simply using the shortcut Ctrl+V.

To delete a flow (or set of flows) and a program (or set a programs), select them then click on .

It's possible to handle several flows at once by pressing Ctrl+Left-click or Shift+Left-click.

Once assembled, a flow can be executed in two ways:

More than one flow can be submitted for execution at once. To make a multiple selection, click over the flows, while Ctrl is pressed or use the arrow keys while Shift is pressed.

After being triggered, the execution can be followed in the same window or, for more detailed information, in the Jobs tab (see Section 4.8, “Following the execution of a flow” and Chapter 6, The Jobs tab).

4.7.2. Setup and run

Many execution details can be set before triggering a job. After setting, click on Run to execute the job.

Figure 4.5. Run and Setup

Execution settings window.

By clicking the button , the following options can be tunned:

1. When will the jobs be executed? This option just appear if multiple jobs are selected for running (multiple execution).
   1. One after another: Jobs are executed one after another, according the order of the flows in the flows' list. Each job is triggered only when the previous job has been concluded.
   2. Simultaneously: All jobs are dispatched simultaneously. Note that this option is not feasible if there is dependency between flows.
2. The beginning of the execution process can be delayed to wait the conclusion of some running job or it can be triggered immediately (default).
3. Where should the jobs be dispatched? Nodes or set of nodes can be specifically choosen to process the jobs. A special option is Choose automatically. It instructs the maestro to submit each job for the node or set of nodes less overloaded of the domain.
4. The number of tasks settled to split the jobs. This parameter is valid only when there is a parallelizable job among the selected jobs. The nominal capacity is given by the number of cores of the group of nodes that are in charge of the execution of the jobs. For non-parallelizable jobs, this parameter is automatically set to 1. For more information, consult Section 8.3, “Parallelized processing”.
5. How does the job compete for resources with other processes of the system? Choosing Dispute resources, each job will be dispatched with default priority. Hence, they will compete equally for system resources with all other running processes. This could overload a processing node with too many running processes. By the other hand, choosing Wait for free resources, the execution of each job will delayed whenever the processing node has other process to operate on. This is particularly interesting we running jobs on desktop machines. In that scenario the user experience will not be degradated by the job execution. For more information, consult Section 8.4, “Priority of execution”.

Note

Decisions made about itens 3, 4 and 5 above can be saved for future executions by checking Save preferences.

Flows submitted for execution generate jobs (see Section 2.3, “GêBR players”). The status and output of the yielded job can be followed in the same window, still in the Flows tab. A bar in the botton of the window will appear to keep the history of the last jobs dispatched for execution. Through buttons in that bar it is possible to switch among the results of the many jobs.

Each job execution is represented in the bar as a button, composed by:

Differently from the Jobs tab, in the Flows tab it is presented just a quick view of the job. However, the arrow button takes the view to the Jobs tab, where full information about the job is available.

When multiple flows are dispatched for execution, instead of staying in the same window, GêBR automatically switches to the Jobs tab, where all the executions can be seen together.

Although GêBR continuously saves all modifications made to flows as well as to projects and lines, sometimes it is useful to dump flows to file. This can be used to share flows among users, for instance, or to generate backups.

Import and Export actions are accessible through the More → Import and More → Export on toolbar.

To export flows, select as many flows as you want with help of the mouse and keys Ctrl (for single selection) or Shift (for multiple selection), then activate the export option at More menu. A dialog box Save flow will pop up, allowing the user to browse for the target directory and chose the filename (GêBR will automatically determine the extension flwx).

In case of importing flows from a file, the imported flows will be listed along with the other flows of the active line, at the bottom of the list and with the suffix (Imported) added.

It is usual in the course of processing data that many flows may depend on some fundamental quantities, like acquisition parameters, for example. Those quantities may be provided explicitly to each flow. Consider however a scenario where one or some of those quantities have to be redefined. The user would have to go through all flows which depend on them making the necessary updates. Despite possible, this procedure is error-prone and time consuming. A better approach would be centralize the definition of those common quantities, in such a way that a change on them would be automatically propagated to all flows where they are employed. This central place for definition of these quantities is the Dictionary of variables.

5.2.1. Variables

Variables are ways to hold numbers or text strings. Numerical variables are defined by arithmetic expressions involving constants and/or other numerical variables. Text string variables are defined by concatenating constant text strings with other numerical or text string variables.

Variables may be used to define programs' parameters directly or by means of inline expressions, i.e. expressions written directly on the parameter's entry box.

The Dictionary of variables is to interface to handle all the variables. It is accessed through the icon , in the More menu of toolbars of the Projects and Lines and Flows tabs.

GêBR has three levels of organization (see Section 2.1, “Projects, lines and flows”). The variables, thus, have three levels of visibility:

• Project's variables are visible to all flows associated to lines of the project;
• Line's variables are visible to all its flows;
• Flow's variables are just visible to the flow itself.

Figure 5.1. Dictionary of variables

A variable with a value may be used with different metrics throughout the flows. Creating a variable for each metric can help in this task. GêBR shows the computed value when the user passes the pointer over the icon . Note that defining distance_cm depending on distance is valid because distance had been defined before.

The dictionary validates the variables dynamically, revalidating and recalculating them as soon as anything is changed in dictionary. Programs with errors are automatically revalidated too (see Section 4.3, “Program states”).

Positioning the pointer over the icon of the variable's type, the user can check the solved expression and see the actual value of the variable. If the Dictionary of variables finds an error among the variables, it is going to exhibit the icon and an explanation of the error. Reordering the variables of the dictionary can be done by drag and drop. Since a variable can just use another variable above it, this feature turns the declaration of variables more flexible and dynamic.

Besides variables and expressions, some predefined functions can be used:

Table 5.1. Available functions

Function	Sintax
Square root	sqrt (value)
Sine	s (value)
Cosine	c (value)
Arctangent	a (value)
Natural logarithm	l (value)
Exponential	e (value)
Bessel	j (order, value)

The character [ (open bracket) is used to see all the available variables for auto-completion while writing an expression.

Navigate over the fields can be done by using the keys Enter, Tab or with the Left button of the mouse.

Tip

To use the variables in text entries, the variable name need to be embraced by square brackets: [ name-of-the-variable ].

To insert a literal square bracket in a text entry, double it, that is, [[ yields is a literal [.

Example 5.1. Using the dictionary

Dictionary is a very useful feature for using a same value multiple times. It is also useful for naming variables, making a flow's parameters more intuitive. For example:

1. Import a demo named Making Data.
2. Check the line named Shot Gathers.
3. Open the Dictionary of variables, on Flows tab.

It can be seen that:

• Some of the variables are line's variables (width, height...). Changing width and weight, all images generated by X Image (on this line) will be changed according to the new value set. Instead of setting each new value, all values can be changed at once.
• Still on Shot Gathers, select the flow Single Shot Sixty Degrees. By checking Dictionary of variables, it's seen that there are some variables related to this flow and these variables are only used on this flow. Also, there are some variables used twice (like dz). It's important to check that the names of each variable represent a meaning on its context : d (z or x) are related to sampling interval; f (z or x) are related to first sample.

The notion of a loop refers to a series of commands that continues to repeat over and over again, possibly changing a little, until a condition is met. For example, suppose the user needs to extract many common-offset sections of a data. Instead of writing a flow to extract each common-offset section individually, or refurbish a base flow, changing manually its target offset, a loop over the offset could be used to sequentially extract all common-offset sections.

The Loop is a special menu from the category Loops that has a totally different usage compared to the remaining menus of GêBR. Here these differences are presented.

Whenever the Loop is added, it appears on the top of the flow. That happens to indicate that the flow is going to be executed more than once, according to the parameters set for loop. (see Section 4.4, “Editing program's parameters” for further details).

Figure 5.2. Loop program

Screenshot of program Loop, added to a flow and properly configured.

After the Loop is added, a new variable, the iter, is available (see Section 5.2, “Using variables”). The value of this special variable is modified on each iteration (increasing or decreasing), according to the parameters set.

Figure 5.3. Loop parameters

Screenshot of the edition from parameters of Loop program, with a simple example of parameters setting.

For instance, the output of each step of the Loop can be defined to a file with a name identified by the step, output-<number-of-steps> (see Figure 5.4, “Usage of iter variable”).

Figure 5.4. Usage of iter variable

This flow, with a Loop with 3 steps, is going to throw the results to three different files, identified by the step of the loop (output-1, output-2 and output-3). Note that, since the output file expects a text string, the iter variable is embraced by square brackets and the output filename is the concatenation of a constant text string, /tmp/output-, and the value of the numerical variable iter.

Tune all program's parameters of a flow can be time consuming. Usually the best setup of parameters is only found by trial and error. It could be distressful have to change a good flow's setup to try a different one, in aim of found something better. To alleviate this stress, GêBR offers the snapshot feature. A snapshot is a record of the complete flow's state at the time, including all programs that build the flow, all program parameter values, the state of the dictionary of variables, and input and output files. After take a snapshot, the user can change anything in the flow's setup without the fear to corrupt the flow, because it is always possible to revert the flow to the state it was when the snapshot was taken.

Snapshot can also be used to keep equally important different states of a flow. For instance, consider a flow to extract a common-offset sections from a data set. One valuable setup is the one that extract the common-offset section for the smallest offset, while other important setup is the one to extract the common-offset section for the biggest offset. Both states can be saved by means of snapshots. Furthermore, both snapshots can be executed at once.

An alternative to snapshots would be is to save many different flows, one for each version, but with the drawback of having a crowded flow's list.

5.4.2. Snapshot actions

The graph below indicates from which version each snapshot was derived from. The start of arrow indicates the origin and the end indicates the derived version. The special mark Now highlights from which snapshot the actual state of the flow derives.

Figure 5.5. Snapshots on GêBR

In this view, the user can perform various actions in the snapshots, like revert, delete and run

In this view, it is possible select as many snapshots as necessary by just clicking over each snapshots. To deselect a snapshot click again over it. To clear the entire selection click on the white area in this view.

Any action taken will affect all selected snapshots. Possible actions are Revert, Delete and Run.

• Revert

  Revert means that the flow will be restored to how it was at the moment the snapshot was taken. If the actual state of flow is unsaved by means of a snapshot, prior the revert action the user is inquired about taking a snapshot of the actual state of the flow or discarding this unsaved state and then proceed.

  Figure 5.6. Dialog of Reverting modified flow

  

  Two option are avaliable to proceed.
  
  
• Delete

  Delete a snapshot is a permanent action, that cannot be undone. Whenever a snapshot is deleted its descendents are linked to the predecessor of the deleted snapshot to keep the idea of ascendence.

  The Delete key can be used instead the context menu option.

• Run

  Running a snapshot is like running a flow (see Section 4.7, “Executing flows”). The advantage of doing this is the possibility of executing a snapshot without having to revert to it. Thus, saved flows can be tested without changing the current one. As with flows, Ctrl+R runs the selected snapshots one after another; Ctrl+Shift+R runs the selected snapshots parallely (keybind activated just if multiple snapshots are selected).

The option More → Include user's commentary allows the user to add comments about the selected flow, just like the option presented in the Projects and Lines tab. Analogously, the option More → View Report allows the user to visualize the report of the current flow. The difference is that the line's report can include the flow's report. Consult Section 3.6, “Report of a project or a line”.

In this tab the user can follow and, if so desired, interrupt the flow's execution. The available commands are:

In the left panel, GêBR presents a list of flows executed by the user, ordered by moment of execution. Each exhibited flow can be in one of four states:

Figure 6.2. Jobs tab left panel

Beside the job name, an icon ( ) appears to represent that this job came from an execution of snapshot (see Section 5.4.2, “Snapshot actions”).

In the upper part, information of the selected flow is exhibited. More informations are shown clicking on Details. Among the exhibited information there are:

Which machines were effectively used in the group and how the distribution of the work was done can be consulted by clicking on .

Figure 6.3. Details of job execution

Job information. The user can consult detailed information about the execution clicking on Details.

Figure 6.4. Jobs outputs

Screenshot of the outputs of a job.

The results (standard output) of the flow are shown. The redirected output are not exhibited. Right-clicking on this window, an Options menu is exhibited, by which the user can enable the automatic word wrap and the automatic scroll of window as the output is being shown.

The user can also consult the command lines executed by GêBR. He just needs to visit the Command Line tab. The command lines are portable and can be copy-pasted to execution on a terminal.

The details the user provides in the Preferences dialog box will be adopted as the default by GêBR. Specifically:

Figure 7.1. Global GêBR preferences dialog box

Preferences menu opens a dialog box where the user edits the user's name, e-mail, menu's directory and the HTML editor.

This option helps the user to configure all the necessary connections to work properly GêBR.

The connection assistant explains how to connect to a maestro, its servers and enable remote browsing into a domain (for more information, see Section 7.3, “Maestro/Nodes configuration” and Section 8.2, “Accessing remote files”).

The Maestro/Nodes Interface has three parts:

Figure 7.2. Maestro / Nodes configuration dialog box

The Maestro/Nodes configuration interface is divided in three parts: maestro, list of nodes and groups of nodes.

In Help → Samples menu, there are samples to be imported.

GêBR offers bundled samples for download in its hostpage, hostpage like gebr-menus-su package. Here are some samples this package provides:

GêBR can take benefit of the resources of multiple processing nodes. To handle it, GêBR is segmented in three layers:

GêBR model comprises communications between processing nodes (see Figure 2.2, “Communication layout between GêBR players”), namely:

All connections are performed using Secure Shell (SSH) protocol. SSH is intended to provide secure encrypted communication over a network. A login password may be asked multiple times to establish such connections. This can be cumbersome, if there are a lot of nodes under the maestro domain.

The SSH public-key authentication is an alternative method to establish connections which eliminates the need of requests for passwords. Despite less annoying, this method is equally secure. It is based on public-key cryptography, where encryption and decryption use public/private key pair for authentication purposes. The maestro knows the public key and only the client knows the associated private key.

By checking the option Use encryption key to automatically authenticate the next session on password dialog, GêBR will use public/private key authentication. Once this operation is successfully done, there will be no need to type the password to connect to that maestro through GêBR. Analogous behavior occurs in the connection between maestros and nodes.

Figure 8.1. GêBR public-key authentication

Suppose a client wants to establish a connection with a domain. The client is requested for login credential, but instead it provides the key associated to the domain. The maestro try to match the client key with one of his own public keys. In positive case, the client is allowed to communicate to that maestro. Otherwise, it requests for the user's password.

Alternatively, the private/public key pair can be created without GêBR (consult here for more information).

GêBR infrastructure comprises GêBR, maestro and nodes as main actors (see Section 8.1, “Intercommunication between players”) and the processing files, therefore, may be on different places than the user's node.

No matter the node where the file is, it can be accessed through the remote navigation (see window below).

In two places GêBR will not browsing the nodes filesystem: Import/Export of projects, lines or flows. On these cases, backup can be saved on the local machine, instead of remote nodes.

Figure 8.2. Remote browsing of files

Example of remote browsing for an output file. Note the bookmarks on the Places panel.

GêBR puts markers (bookmarks) to the important folders of the line in context (see Section 3.3, “Important folders of a line”). They aim to facilitate the access to the files of the line.

GêBR takes advantage of the multi-core feature of most of the recent machines. The execution of repetitive flows can be optimized by this resource. If the flow has Loops and is parallelizable (given some criteria, shown below), the execution performance based on the number of processors can be adjusted.

GêBR also takes advantage of the number of processing nodes connected to the user's maestro. The resources of every node can be effectively employed to improve the performance.

Accordingly, GêBR can parallelize the flow if:

and if the flow is parallelizable.

To be considered parallelizable, besides having a loop, a flow must achieve one, and just one, of these criteria:

The level of parallelism of a job execution can be adjusted by the Advanced Execution settings (see Section 4.7.2, “Setup and run”).

In case the flow is not parallelizable (i.e., does not fit any of the above conditions), GêBR runs the job in the choosen node.

Computers, nowadays, are multitasked, what means that multiple things can be done at the same time. When many tasks are executed at the same time, the computer can get overloaded and decrease its performance. Seismic processing, particularly, can exhaust the computer resources.

GêBR has a feature that overcomes the issue of overloading due to multitasking, by enabling the execution of the flows in a Wait for free resources state:

Two options are available (see Section 4.7.2, “Setup and run”):

Technically, when running in Wait for free resources mode, GêBR will reduce the execution priority of the task, meaning it will tell the computer that "it can wait more important things to be done". This is the case when the user has other things to do while waits the calculations to be done.

The Share available resources mode means GêBR will use greater run priority for the task, and that implies it will act as a foreground process, demanding more resources. It's the "I need this done now" mode, when the user needs the job to be finished as soon as possible, and doesn't care if it will fight for resources with other programs.

If GêBR is the only program executing on the node, i.e., it doesn't have a challenger for the computer resources, then both states corresponds to the same situation. This is the "nightly job" situation, when (theoretically) no one is using the processing nodes and some jobs are left to be done for the next morning.

Some programs, known as parallel programs, deal themselves with the distribution of their computations among many nodes. In this way, those programs are much more efficient, exploit all available resources to run faster. Technically, they employ a infrastructure known as MPI. GêBR supports parallel programs.

There are many implementations (flavors) of MPI, but the most widely used are OpenMPI and MPICH2. OpenMPI is an open source implementation and has influence of three earlier approaches: FT-MPI, LA-MPI and LAM/MPI. The MPICH2 is another widely used implementation and is based on the MPI-2.2 standard.

GêBR supports both OpenMPI and MPICH2. However, MPI programs can only run on nodes that support the execution of MPI. Thus, for GêBR support of MPI, the user must have acces to nodes/clusters that also support it.

In the maestro/nodes interface, in the MPI column, an icon indicates whether the node supports MPI. Roll over the icon to check the flavors of MPI available on that processing nodes. The parallel program can be executed just on processing nodes that support the same flavor as the one used in it.

Figure 8.3. Indication of MPI availability

The second column indicates the types (flavors) of MPI available in the nodes.

To run an MPI program, first it's necessary create a menu in DêBR and choose the proper MPI implementation to the program. Then import it in GêBR. With double-click over the MPI program in the Flows tab, the number of processes to be used by that MPI call can be seen.

Figure 8.4. MPI settings

The np value is set according to the speed value set in the Advanced Execution dialog (see Section 4.7.2, “Setup and run”).

The system administrator can configure global options appliable to everyone that starts GêBR for the first time.

GêBR verifies the existence of an environment variable (GEBR_DEFAULT_MAESTRO) to suggest a maestro. The syntax of this variable is maestro_A, description_A; maestro_B, description_B.

For instance, if the administrator sets GEBR_DEFAULT_MAESTRO as 127.0.0.1, My first maestro; 100.00.00.0, My second maestro; then, on the first time or through Connection Assistant (see Section 7.2, “Connection assistant”), GêBR will offer the following options:

Additionally, GêBR can also automatically add processing nodes. This configuration can be done through a file in the path /etc/gebr/servers.conf.

The syntax of this file must be the names of the nodes enclosed by brackets.

For instance, if the administrator sets /etc/gebr/servers.conf with

				
				[node1]
				[node2]
				[node3]
				
	

then for every user with that maestro, the processing nodes node1, node2 and node3 will be available.