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 three main player categories: GêBR (the interface itself), maestros, and nodes. But who are those guys?

The GêBR interface, sometimes referred as GêBR only, is the graphical interface with whom the user interacts with 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 this set of machines to run flows. Those machines, or processing nodes, are simply referenced in the GêBR as nodes. 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.

However, GêBR does not talk directly to the nodes. This communication is stablished with the intervenience of another player, the maestro. 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, 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.

Figure 2.2. Communication layout between GêBR players

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

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 requested in the creation. Such 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 belew will be requested to complete the operation:

This information is aided by an assistant dialog. 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 maestro (see Section 7.3, “Maestro/Nodes configuration”). Otherwise, GêBR will not be able to submit flows for running, since this is done through the maestro intervenience.

To delete a line, select it and then left-click on .

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 folders are the HOME and IMPORT. HOME is automatically set to the path of the user area. The IMPORT, unlike the previous mentioned folders, is not associated to the BASE path and can be independently set.

For instance, suppose we are going to set the important folders of a line. The IMPORT is totally independent and can be set anywhere, e.g., /tmp/data. If the 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 directories structure associated to the current line:

This standard directory structure eases the task of managing the data related to lines. In the input/ouput/log fields, this feature can be used by embracing them in angle bracktes (for instance, <BASE>). For more information, consult Section 4.5, “Editing the flow's input and output files”.

GêBR supports only one connected maestro at time. However, there may be several maestros at disposal, one for the University A and another for University B, for example.

Whenever a maestro is connected, all lines associates to other maestros will be unavailable for edition. However, a line can be migrated from its original maestro to the connected one. To do so, the line must be selected. In the right-hand side panel, an icon in the upper left corner indicates whether the maestro defined for the line is connected or not. In case the original maestro is not the connected one, by clicking over that icon, GêBR will offer two options:

Figure 3.2. Dialog for lines from disconnected maestros

Options available when it's desired to edit/run a line associated to a disconnected maestro.

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 and have an automatic report generation. To edit their commentaries, follow the steps:

Figure 3.3. Built-in comment editor

The comment editor window.

The report can be visualized by clicking over 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 generated report for that project or line. This window has some functionalities that are mentioned below:

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 divided 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 domain 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 be appear on the left side of the main window. The right side will show information about this flow, like its title, description and modified date.

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 selected together and executed. 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 over , it can be set:

1. How jobs are going to be executed. This option just appear if multiple jobs are selected for running (multiple execution).
   1. One after another: flows can be executed one after another, in the order they are on the flows list. Each flow awaits for the end of the previous job to be executed.
   2. Simultaneously: flows are executed parallely, all of them at the same time. It is just possible if there is no dependency between flows.
2. Whether jobs must wait for some task or not. Jobs can be triggered after the ending of another task or immediately by clicking the execution button.
3. Where jobs must be dispatched. Nodes or set of nodes can be choosen to process the jobs. A special option is the Choose automatically. It allows the maestro to search for the least overloaded nodes or set of nodes. If the use changes this parameter, GêBR shows the number of cores of the choosen group.
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, according to the choice of the group's nodes. For non-parallelizable jobs, this parameter is automatically set to 1. For more information, consult Section 8.3, “Parallelized processing”.
5. How a job must compete with other processes on the system. In overloaded nodes, this option can make all the difference because jobs will have less priority than other processes running on the system. For more information, consult Section 8.4, “Priority of execution”.

Note

Itens 3, 4 and 5 can be saved for future executions by checking Save Preferences.

After a flow has been sent to execution, 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:

Different from the Jobs tab, in the Flows tab it is presented just a quick view of the job. Indeed, the aim of this features is not to present a full view of the job, but to avoid the switching of tabs to follow jobs. The arrow takes to the Jobs tab, where a complete view of the flow execution can be consulted.

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 all together.

Although GêBR maintains all the data, sometimes it's necessary to copy the flow to files for sharing.

In the window Save flow, navigate to a desired directory and type a name for the file (GêBR will automatically determine the extension flw). To do so:

In case of Import, the imported flow will be listed along with any other flows of the selected line. Otherwise, in case of Export, the file containing the exported flow will be created.

It is usual in the course of processing a data that many flows 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

The Dictionary of variables is an 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 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 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 on the icon of the variable type, the user can check the solved expression. 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 brackets) is used to see all the available variables for auto-completion.

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 fields like Text, the variable name need to be embraced by square brackets [ name-of-the-variable ].

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.

5.2.2. The variable iter

GêBR allows the execution of repetitive procedures by creating flows with Loops (see Section 5.4, “Flows with loops”). With Loops, the user has access to a special variable called iter.

Upon execution, the user might want to identify what is the current step of the Loop. The iter variable is devised with this aim.

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.2, “Usage of iter variable”).

Figure 5.2. Usage of iter variable

This flow with a Loop program and number of loops equal to 3, is going to throw the results to three different files, identified by the step of the loop (output-1, output-2 and output-3).

There are situations when working with GêBR it will be useful to use an existing flow as a basis to create new flows. For example, to experiment with flows that are only slightly different from one another, however without having to discard or modify the original flow.

A way to do this is to copy and paste the flow (see the section Section 4.6, “Copying, pasting and deleting flows and programs”. Another way is to take a snapshot of the original flow, through a snapshot, GêBR stores the settings of a flow so it's easy come back to it later.

5.3.2. Snapshot actions

A user that uses different versions of the same flow may also be benefited by the use of snapshots. An option would be to save many different flows, one for each version, which drawback is the pollution of the flows tab. Another option, using the feature above, is taking a snapshot of each version of the flow.

Figure 5.4. Snapshots on GêBR

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

The graph indicates from which version each snapshot was derived from. The start of arrow indicates the origin and the end indicates the modified version.

Caution

GêBR always preserves the setup of the flow. Even if the computer was turned off, this list will be recovered when GêBR is opened again. However, if the flow was deleted all the saved states will immediately disappear forever.

Through a right-click over the target snapshot, the user has the option to Revert, Delete or Run it. The right-click over the current stage (Now) allows the user to Run the current flow or to take a snapshot thereof.

In this view, also is possible use multiple selection just click over several snapshots and the actions are disposable through the right-click over a snapshot. After to choose several snapshots and the action, this action will be applied in all selected snapshots.

To deselect a snapshot is as easy as select one, the user just need to click over the undesired snapshot. Also is possible deselect all the selected snapshots by clicking on the white area in this view.

• Revert

  If a snapshot of a flow was taken and for some reason undesired modifications were made to it, is possible to revert to another one through double-click on that. Whenever a snapshot is reverted, the dialog Reverting modified flow will appear.

  Figure 5.5. Dialog of Reverting modified flow

  

  Two option are avaliable to proceed.
  
  
  • Take a snapshot: a dialog to input a description will appear, where is possible save this new snapshot.
  • Proceed discarding changes: GêBR will simply revert to the chosen snapshot without saving the current state.

  Tip

  If the current state was previously saved, GêBR recommends that the user click on Proceed discarding changes, in the dialog box Backup Current State, as to avoid a bloated snapshot view.

• Delete

  The delete of a snapshot is a permanently action. After do that, this snapshot will disappear and cannot be recovered.

  GêBR deals with the idea of origin of the snapshot. In the graph of the figure, 'B1' and 'B2' come from 'B' which, by its turn, comes from 'A'. If the user deletes 'B', GêBR will consider 'B1'and 'B2' as originated from 'A'.

• 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 Delete key deletes the selected snapshots;

The notion of a loop refers to a series of commands that continues to repeat over and over again, possibly changing a little, untill a condition is met. For example, suppose the user needs to generate one plot for each of a set of functions. One option is to create many flows, each one based in a function, that generates the plots. Another simpler option would be to create a single flow that, for each function, generates a plot. The loop program allows it in GêBR.

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

Whenever the program 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 the program. (see Section 4.4, “Editing program's parameters” for further details).

Figure 5.6. 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 decrementing), according to the parameters set.

Figure 5.7. Loop parameters

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

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.3.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. Jobs tab Right Panel

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 the user to connect to a maestro, its servers and enable remote browsing (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 maestro. The client is requested for login credential, but instead it provides the key associated to the maestro. 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.