• Skip to main content
  • Skip to footer

INT

Empowering Visualization

CONTACT US SUPPORT
MENUMENU
  • Products
    • Overview
    • IVAAP™
    • INTViewer™
    • GeoToolkit™
    • Product Overview
  • Demos
    • GeoToolkit Demos
    • IVAAP Demos
  • Success Stories
  • Solutions
    • Overview
    • For E&P
    • For OSDU Visualization
    • For Cloud Partners
    • For Machine Learning
    • For CCUS
    • For Geothermal Energy
    • For Wind Energy
    • For Enterprise
    • Tools for Developers
    • Services Overview
  • Resources
    • Blog
    • Developer Community
    • FAQ
    • INT Resources Library
  • About
    • Overview
    • News
    • Events
    • Careers
    • Meet Our Team
    • About INT

INTViewer

May 15 2019

5 Simple Techniques to Avoid Bugs While Programming

Programming is an activity that requires a special set of cognitive skills. While the industry has developed processes and tools to ensure the quality of software artifacts, the act of writing code is a craft in itself. Developers pride themselves on the “big picture” results they achieve, but the activity of programming is definitely a humbling experience: It’s easy to introduce bugs, and regardless of whether I catch them right away or later in the pipeline, I hate to be reminded I am inherently flawed and have introduced a defect. For this article, I will focus on simple methods to avoid bugs, not before or after you write code, but while you write that code.

Leverage the Hints from the IDE

This one should be obvious to most programmers, but the reality is that the tools we use are a bit smarter than what we give them credit for. It’s easy to miss these hints. They are sometimes buried in build logs, drowned in a sea of flags, visually too subtle to attract our much-needed attention. Listen to your Integrated Development Environment (IDE)—it is telling you something.

One of the most obvious signs that something is up with your code is when the IDE tells you that you are not using a variable you introduced earlier in your code. You had some intent for this variable, but that intent got lost while working on some other aspect. There is certainly a bug lurking there.

Another useful alert is when the IDE detects that there is a logical path for a NullPointerException. Maybe the most common case is well taken care of, but there seems to be a road less-travelled to this ubiquitous exception.

The activity of writing code forces you to concentrate on the text you are typing while keeping a stack of other concerns in mind. This cognitive load is already heavy; I like to reduce it by removing ambiguities. The IDE will tell you when you are using the same variable name for an instance variable and a local variable. I don’t need to risk being confused about which one I am manipulating. I’ll follow my digital assistant’s advice and rename the local variable in question.

Break up Your Content

The brain can only keep so much information. And each coding window only shows you about 50 lines. When the code grows, so does the likelihood of bugs, just from not remembering details implemented a few invisible lines away. One simple technique to avoid such troubles is to break up the code. Keep the methods short. Ideally, a well-focused class shouldn’t have more than 200 lines. It’s not always possible, but where it is, you can avoid bugs when each class has only one responsibility. The class’ code itself is easy to review, and its function is easy to remember in other contexts. If you just wrote a large body of code in one class, it’s time to break it up into smaller pieces.

This is nothing new. When the metric of cyclomatic complexity was developed in 1976, its first applications tried to limit the complexity of each module, splitting them into smaller modules. These modules became easier to write, and easier to test, too. If the most likely place for defects is where complexity lies, reducing complexity automatically reduces the rate of defects.

It’s not just the height of your screen that matters when having “too much to code” might be “too much to cope.” The width matters, too. This is actually a classic source of bugs: a line goes beyond what’s visible without scrolling, meaning it’s not being looked at as often as other lines. Code reviewed less is more likely to be incorrect. Long lines are also bug candidates when overly confident IDEs autofill their content over the developer’s watchful eyes. The simple solution is to break up these long lines, for example, inserting carriage returns when they go over 120 characters. The IDE will often show you this limit graphically.

Use the Java Type System

Object-oriented programming is a great way to abstract sequential instructions into relationships and behaviors. The Java type system is quite powerful. When two pieces of code interact, the parameters of this interaction typically need to meet specific type requirements, so the compiler will prevent code being typed from using the wrong object type in the wrong context.

You can use this type checking to your advantage to reduce opportunities for bugs. Writing a program often requires code where mundane objects are being passed around—a collection of names, an Integer identifying a record, etc. If you inadvertently pass the wrong list of Strings, the compiler won’t be any help. Instead of passing List<String> or Integer, create your own objects, such as “NamesCollection” and “RecordId.” By forcing the passing of functional objects instead of generic ones, you will know immediately, as you type, that you just picked up the wrong collection or the wrong number.

Don’t Leave Your Code to Chance

I have seen many cases where two (or more) classes have the exact same name. They have different package names, but package names are hidden away at the very beginning of each class that uses another class. It’s a good idea to give classes unique names across your code base. This will make sure there is no ambiguity around which one a developer is using. Murphy’s law is not your friend—you will inevitably pick the wrong one otherwise.

The behavior of HashMaps may also be a source of hard-to-troubleshoot bugs. The Java Virtual Machine tends to optimize the behavior of HashMaps when the application load grows. What this means for developers is that you will observe one behavior during development, and a different behavior in production. To avoid this kind of head-scratching riddle, I have learned to use LinkedHashMaps even when not needed as they will always return entries in a consistent manner. This is a trick to use wisely: the performance cost of using LinkedHashMaps should be weighed against the risk of having to solve a problem that only happens in production.

Reuse Existing Code

At the end of the day, there is so much to keep track of, just writing code is doomed to produce bugs. The simplest way to avoid writing bugs is not write any code at all, and leverage some other battle-tested component instead.

Reusing code is the ultimate simplification technique, but I am not just talking about integrating other people’s work into your own software. The code you already have is the result of many refactorings. It has real-world experience you are missing (or that you forgot). Use the code you already have as your template. If the quality of your template is not what you need, refactor this code, then reuse it. There shouldn’t be in your program “two best patterns” to do the same thing.

As I implement a new feature, I typically look at similar code doing similar things: how classes, methods, and variables are (meaningfully) named, which properties and behaviors are exposed, how objects interact with each other, etc. In all the bodies of code I have maintained for several years, I have found that consistency is the easiest constraint to follow, to teach, and the one that brings the most benefits in terms of overall quality.

Filed Under: GeoToolkit, HTML5Viewer, INTViewer, IVAAP Tagged With: developing, IDE, java, programming

Jan 04 2019

What We Learned about the Future of NetBeans from the Last 2 Years

It’s been two years since Oracle announced the donation of the NetBeans source code to the Apache software foundation. This move was much more than a licensing change — it was a bit of a new beginning for NetBeans.

The NetBeans IDE is well liked at INT. In fact, INTViewer is built on top of the NetBeans platform, and the IVAAP backend was entirely written with the NetBeans IDE. With the release of NetBeans 10, now is a good time to look back and recognize the changes that this transition to Apache brought.

Better Licensing
Under Oracle’s stewardship, the NetBeans source code was available under two licenses: a Common Development and Distribution License (CDDL) and a GNU General Public License (GPL). The CDDL is not well known, and the GPL sometimes carries stigma. The license move is a clear win for the platform as Apache is appreciated in the Java community for its business-friendly license and ubiquitous libraries.

Open Governance
The Apache NetBeans project is still “incubating.” The incubation process allows the foundation to assess whether the donated code complies with legal standards and how the community adheres to Apache’s guiding principles. These principles are centered around openness and collaboration. You can see it at work on NetBeans’ own website: all communications are recorded and shared. This is actually a requirement from the Apache foundation to use mailing lists. No conversations behind closed doors. No secret agenda. When decisions are made, you can see how the consensus was built. The NetBeans project didn’t just get a “new home,” it inherited a renewed philosophy, a new process, moving from “open source” to “open governance.”

Ongoing Support
Oracle has been a significant contributor to NetBeans in the past. Despite the spin off, Oracle’s contributions continue to this day — the NetBeans project received in June a second code donation from Oracle, a donation that will enable JakartaEE projects. Two years ago, observers were worried that Oracle might be “abandoning” NetBeans to Apache. However, the last two years have proved that Oracle still intends to spend resources on NetBeans.

The move to Apache was also a good opportunity to modernize the community tools: Bugzilla was retired, making room for JIRA, and self-hosted Mercurial was replaced by Git, hosted on GitHub. These changes make contributions from developers easier to make, giving the community much more freedom to control its future.

The timing of this transition wasn’t the best. Effort that would have normally been spent by the NetBeans community to support Java 9, 10, and 11 was spent instead meeting Apache’s legal requirements. The release of NetBeans 10 officially closes this chapter. The NetBeans developers need to be recognized for their efforts during these two years. As all Java developers can attest, the transition to Java 11 of any code base is a challenge. This was certainly even more true for a large code base such as NetBeans’.

What’s Next for NetBeans?
This chapter has yet to be written. Discussions point to frequent updates, maybe every 6 months. Meanwhile, INT is working actively to integrate the NetBeans 10 platform to INTViewer. Personally, I feel that the NetBeans project is likely to attract a new crowd of developers. Developers who have an itch to scratch. Since the users of the NetBeans IDE are developers themselves, there is a definite sense that filing bug reports or proposing new features won’t be enough to get things done. Pull requests make it easier than ever to submit changes and I plan to scratch long-time itches myself — maybe INTViewer would benefit from some tweaks to the NetBeans window system. It’s time for all of us to use these newfound abilities.

Visit our products page for more information about INTViewer or IVAAP or contact us for a demo.


Filed Under: INTViewer, IVAAP Tagged With: INTViewer, ivaap, NetBeans

Dec 20 2018

How Window Synchronization Facilitates Visualization of a Large Number of Datasets

When we demo INTViewer, we typically use a laptop. We go to a customer site, project INTViewer on a big screen and open a few datasets to showcase the product. However, these short demos don’t really do justice to the capabilities of this software. While some customers will use the portability of INTViewer to present their data, others will use INTViewer on a workstation, with multiple monitors. And instead of opening a handful of windows, they will open a few dozen.

The typical use case for opening a large number of windows is when you want to monitor the multiple steps of a processing workflow. In such a use case where datasets are compared, it’s important that all visualizations share the same settings. INTViewer makes it really easy to open dozens of datasets at once. You can select a directory and open in one click all the datasets within that directory. But this is not where INTViewer’s productivity stops. Automatic synchronization facilitates the management of all these windows.

Synchronizing Windows

There are three types of synchronization: window, data selection, and layer. When you synchronize windows, you make sure that all windows use the same scale — when you zoom, all windows zoom at the same time; when you move the cursor in one window, the cursor shows the equivalent traces in all windows; and when you need to change annotations and add a header to the horizontal axis, this header is added automatically to all windows. Window synchronization is enabled by default so that geoscientists can focus on comparing their data, not on configuring their software.

Synchronizing Data Selections

When you control the multiple processing steps of one dataset, you need to make sure that you are comparing the same data slices. INTViewer offers multiple options to decide how to synchronize data selections as you navigate through your data. For example, when you open several volumes at once, they will all show the same INLINE slice by default. Each time you press the + button in the toolbar, the INLINE slice shown will change automatically, for all volumes.

You can also opt to show open different slices of the same volume. The offset between slices will also be kept as you navigate through your volume. And it’s not just XSection windows that synchronize their selection. 3D and Map windows also update when you change the slice of data you are visualizing.

Synchronizing Layers

The option to synchronize layers is not enabled by default, and it tends to be used only by power users. For example, when you visualize two datasets or two slices of the same dataset, you might want to synchronize their display attributes so that the same color bar is used by all visualizations, in one click. But it’s not just color bars that can be synchronized. The control over which attributes automatically synchronize is fine-grained, allowing a wide range of automatism.

Synchronization is a feature that has been built in to INTViewer since the beginning. Layer synchronization is the lesser used option of all 3 synchronization types. I found that many users tend to apply the same “profiles” to multiple layers instead of synchronizing them.

Grouping Windows

One other reason why INTViewer users might open a large number of datasets at the same time is the same reason why you have dozens of browser windows open right now: You are multitasking. Even within the same customer survey, you might work on multiple areas or multiple workflows. You could open multiple instances of INTViewer for each task, but there is a better way. INTViewer 2018 introduces the concept of grouped windows. By grouping windows, you isolate a logical group of windows from the others, making sure they only synchronize with windows from the same group.

Creating window groups is actually quite simple, and if you are a regular user of INTViewer, you already know how to do this. Just combine the plot of two windows into one, and you have a group. Isolating these two windows from the other windows on your desktop is then just one checkbox away.

Combining windows does affect the layout of your visualization. If combining windows is not a practical option, you can also create groups from the Desktop window. Pick several windows, right-click, and group them into a so called “window folder”.

Grouping Layers

The same concept is available when you need to limit the synchronization of layers to a logical set. Just like windows, layers can be grouped in folders. I have often seen layer folders used as part of custom plugins or scripts creating layers automatically. INTViewer is a platform, and its synchronization features are accessible from Python scripts and Java plugins. Developers use layer folders programmatically to setup on behalf of the user how multiple visualizations will behave once created.

Synchronization is a powerful mechanism within INTViewer. It “just works” by default, but it can be customized when your workflow demands it.

Visit our products page for more information about INTViewer or contact us for a demo.


Filed Under: INTViewer Tagged With: INTViewer

Sep 11 2018

Using INTViewer to Visualize Earthquakes and Other Seismic Activity

I often have a hard time explaining to friends and family what exactly INTViewer does. The moment I use the word “seismic,” the listener’s mind automatically shifts to the topics of seismic activity and earthquakes, and I need to explain oil & gas exploration technologies before I even get to the software. By then, I have lost my audience.

Today, I’ll try a different technique: I’ll describe the capabilities of INTViewer that actually cater to earthquake mapping. I will show how you can use the built-in capabilities of INTViewer to map recent earthquake activities.

To prepare for this blog article, I needed data. The United States Geological Survey (USGS) provides recent earthquake data on their website.

This data is provided in QuakeML format. INTViewer has a free plugin called Microseismic that opens QuakeML files directly. In this example, I downloaded the “All Earthquakes” QuakeML file for the past 30 days (all_month.quakeml), it opened right away, and after a few clicks, I got the visualization below:

 

World earthquake data last 30 days
World earthquakes from the last 30 days
Map is provided by Bing Maps
Data is provided by United States Geological Survey (USGS)

 

The color of each dot identifies the magnitude of each recorded event. I choose Bing Maps to show these events in context, requiring the installation of the free RemoteMap plugin.

There are a few websites proposing similar visualizations, but INTViewer can go further than these websites. For this example, I went to another data source, the International Seismological Centre (ISC) in the UK. This association compiles records of the earth seismicity, and provides a convenient way to search those records.

I decided to map earthquakes in Peru (longitudes from -83° to -65°, latitudes from -3° to -20°), starting from the 1970s to today. In the visualization below, the color and size of each dot identifies the depth of each recorded event.

Beachballs-coast
Peru earthquakes since 1970, showing depth variations
Map is provided by Bing Maps
Data retrieved from the ISC web site:
International Seismological Centre, On-line Bulletin

 

Seismologists typically use another type of visualization to identify the fault-plane solution, also known as focal mechanism. This mechanism describes the orientation of the fault plane that slipped as well as the slip vector. The colloquial name for this visualization is beachballs. Here are sample beachball representations provided by the Penn-State Geosciences Department:

focal-mechanisms
Focal mechanism examples

 

A single beachball describes three attributes of a seismic event: the strike, the dip, and the rake. These three attributes are present in the ISC exports and can be visualized in the form of beachballs in INTViewer. After changing the display options of my Peru session, I got the result below:

Beachballs-coast-2
Peru earthquakes since 1970, showing focal mechanisms
Data retrieved from the ISC web site:
International Seismological Centre, On-line Bulletin

 

Visualizing nature’s earthquakes is, of course, not a typical use of INTViewer, since most will use it as part of their seismic exploration QA workflow using data from manmade seismic events, but it is an interesting way to demonstrate how it works.

For more information about INTViewer, visit the INTViewer product page, or contact us for a free trial.


Filed Under: INTViewer Tagged With: beachball, earthquake data, INTViewer, seismic data

Aug 10 2018

5 Ways INTViewer Makes Offline Visualization Possible

I often say that INTViewer is a bit of a Swiss Army knife. It serves multiple purposes, and each company finds a different use. This makes it hard to decide which feature to highlight. In the past few years, as the industry moved to the cloud, we created a companion for INTViewer: INTGeoServer, which makes it easy to visualize data beyond the bounds of your network. This year, with the new release of INTViewer approaching, I will highlight the opposite feature of INTViewer: its ability to work offline, disconnected from the world.

Simple Installation and Small Footprint

There are several degrees of offline work. Wireless Seismic has worked with TotalEnergies to install seismic sensors in inaccessible areas, and they used INTViewer to monitor this process using drones. Data management companies routinely use INTViewer to show their data library to potential customers. These two use cases both take advantage of the fact that INTViewer can be installed on a laptop. It is easy to install and doesn’t require a backend server to visualize data. It is also frugal when it comes to memory footprint and disk usage. Both qualities are appreciated when you don’t have the luxury of a full workstation.

Smart Decimation Without Loss of Resolution

Seismic datasets tend to be very large. How do you fit terabytes of data on a laptop? INTViewer has a Lattice Decimation plugin that allows you to carry full-resolution copies of your data, but with decimation applied, reducing its size, making it possible for data library vendors to showcase their data without carrying a full copy. And with the session mechanism, it takes just one click to bring up a particular survey that a customer is interested in.

Versatile Window System

The user interface is also designed with laptop users in mind. When you use INTViewer to visualize the output of processing steps, you typically use INTViewer’s TABS mode, splitting your data between several screens. Most laptops only offer one screen and the alternate FRAMES mode allows an optimal use of screen real estate while opening multiple datasets.

Customizable Without IT Help

Being offline also means that you won’t get updates for a while. This is a common occurrence on survey boats, where the environment is tightly controlled and internet access is limited. To compensate for the lack of software updates, INTViewer users end up relying on Python to automate their work rather than waiting for the back office to send the latest version of a much-needed plugin. INTViewer lets laptop users be truly independent.

Borrow Licenses from Your Company’s License Server

None of this would matter if INTViewer’s license was restrictive. When you acquire an INTViewer license, you have several options. Large installations prefer a pool of licenses accessible from a license server, but this option doesn’t work when you go offline. This is why INT has always offered licenses that are tied to particular machines, or even USB dongles, without the need to connect to a server. However, until now, companies had to choose the type of license right away. The new release of INTViewer offers more versatility by enabling borrowing of licenses. You can still host your licenses on a server, borrow one of them on your laptop, then disconnect from the network completely. INTViewer will still open and function fully, despite being disconnected from a license server, for the specified duration. With this new feature, we hope to find more users carrying INTViewer with them, on the go, wherever Oil & Gas takes them.

For more information about INTViewer, visit the INTViewer product page, or contact us for a free trial.


Filed Under: INTViewer Tagged With: INTViewer, offline visualization

  • « Go to Previous Page
  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Go to page 4
  • Interim pages omitted …
  • Go to page 6
  • Go to Next Page »

Footer

Solutions

  • For E&P
  • For OSDU Visualization
  • For Cloud Partners
  • For Machine Learning
  • For CCUS
  • For Geothermal Energy
  • For Wind Energy
  • For Enterprise
  • Tools for Developers
  • Customer Success Stories

Products

  • IVAAP
  • GeoToolkit
  • INTViewer
  • IVAAP Demos
  • GeoToolkit Demos

About

  • News
  • Events
  • Careers
  • Management Team

Resources

  • Blog
  • FAQ

Support

  • JIRA
  • Developer Community

Contact

INT logo
© 1989–2023 Interactive Network Technologies, Inc.
Privacy Policy
  • Careers
  • Contact Us
  • Search

COPYRIGHT © 2023 INTERACTIVE NETWORK TECHNOLOGIES, Inc