Wolfram Blog http://blog.wolfram.com News, views, and ideas from the front lines at Wolfram Research. Thu, 27 Apr 2017 15:59:12 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 Using the Sense HAT on a Raspberry Pi with Mathematica 11 http://blog.wolfram.com/2017/04/27/using-the-sense-hat-on-a-raspberry-pi-with-mathematica-11/ http://blog.wolfram.com/2017/04/27/using-the-sense-hat-on-a-raspberry-pi-with-mathematica-11/#comments Thu, 27 Apr 2017 15:44:24 +0000 Brett Haines http://blog.internal.wolfram.com/?p=35932 Raspberry Pi with Sense HAT

Ever since the partnership between the Raspberry Pi Foundation and Wolfram Research began, people have been excited to discover—and are often surprised by—the power and ease of using the Wolfram Language on a Raspberry Pi. The Wolfram Language’s utility is expanded even more with the addition of the Sense HAT, a module that gives the Raspberry Pi access to an LED array and a collection of environmental and movement sensors. This gives users the ability to read in data from the physical world and display or manipulate it in the Wolfram Language with simple, one-line functions. With the release of Mathematica 11, I’ve been working hard to refine functions that connect to the Sense HAT, allowing Mathematica to communicate directly with the device.

The Sense HAT functionality is built on Wolfram’s Device Driver Framework, so connecting to the device is incredibly simple. To start, use the DeviceOpen function to establish a connection. This will return a DeviceObject, which we will use later to tell Mathematica which device we are wanting to read from or write to.

hat = DeviceOpen["SenseHAT"]

In the case of the Sense HAT, there are three onboard sensors that Mathematica can read from. Accessing the data from these sensors is as easy as calling DeviceRead with the name of the measurement wanted. For instance:

temp = DeviceRead[hat, "Temperature"] hum = DeviceRead[hat, "Humidity"]

temp = DeviceRead[hat, "Temperature"]

hum = DeviceRead[hat, "Humidity"]

There are a total of seven measurements that can be read from the Sense HAT: temperature, humidity, air pressure, acceleration, rotation, magnetic field and orientation. All readings are returned with appropriate units, making it easy to convert the values to other formats if necessary.

accel = DeviceRead[hat, "Acceleration"] accelSI = UnitConvert[accel, "Meters"/"Seconds"^2]

accel = DeviceRead[hat, "Acceleration"]

accelSI = UnitConvert[accel, "Meters"/"Seconds"^2]

The other physical component of the Sense HAT is the 8-by-8 LED array. Similar to reading data with DeviceRead, it is only a matter of calling the DeviceWrite function to send either an image or a string to the array. For strings, the text scrolls across the device sideways. You can manipulate the speed and color of the scrolling text with relevant options as well.

DeviceWrite[hat, "Hello, world!"]

DeviceWrite[hat, {"Now in color!", "ScrollSpeed" \[RightArrow] 0.25,    "Color" \[RightArrow] {255, 0, 128}}]

Alternatively, the Sense HAT can receive an 8-by-8 list of RGB values to be displayed on the LED array. Using this method, it’s possible to display small images on the screen of the Sense HAT.

Sense HAT on Raspberry Pi--color LED array list

DeviceWrite[hat, list];

Here is a picture of what this looks like when written to a Sense HAT:

Sense HAT on Raspberry P--color LED array

Using these functions, you can write Mathematica programs that process the data received from the sensors on the Sense HAT. For example, here is a demo I ran at the Wolfram Technology Conference in October 2016. It reads the temperature, humidity and air pressure around the Pi every five minutes and pushes that data to the Wolfram Data Drop.

db = CreateDatabin[]

SaveReadingToDataDrop[    bin_Databin] := (Module[{dev, hum, temp, pres},      dev = DeviceOpen["SenseHAT"];     temp = DeviceRead[dev, "Temperature"];     pres = DeviceRead[dev, "Pressure"];     hum = DeviceRead[dev, "Humidity"];     DatabinAdd[      bin, <|"temperature" -> temp, "humidity" -> hum,        "air pressure" -> pres|>];     DeviceClose[dev];]);

cronTask = RunScheduledTask[SaveReadingToDataDrop[db], 300]

The above function generates a new databin to record data to, but what does that data look like once it’s been recorded? Let’s look at the recordings I made at the aforementioned Wolfram Technology Conference.

That data can be downloaded into Mathematica by anyone anytime after the conference to show the changes in atmospheric conditions over the course of the conference using DateListPlot. Below, you can see the rise in air pressure inside the conference center as more people gathered to see the many demos Wolfram employees had set up, followed by a drop as the conference ended.

DateListPlot[Databin["gwSkMvMW"]]["air pressure"]

Another demo I ran at the Wolfram Tech Conference made use of DeviceWrite. Using the Wolfram Language’s financial database, I turned the Sense HAT into a miniature stock ticker. This demo downloads the current stock market data from Wolfram’s servers, then displays them by picking a random stock from the list and showing the stock’s name and price on the Sense HAT’s LED array.

StockTickerPi[    dev_DeviceObject] := (Module[{len, price, str, stock, stockList},      stockList = FinancialData["NYSE:*", "Lookup"];     Do[stock = RandomChoice[stockList];      price = FinancialData[stock];      If[Head[price] === Real,        str = StringDrop[ToString[stock], 5] <> "$" <> ToString[price];       DeviceWrite[        dev, {str, "ScrollSpeed" \[RightArrow] 0.05,          "Color" -> {200, 0, 0}}]], 100];]);


The final demo that was run at the Wolfram Tech Conference this year used the Sense HAT’s LED array to run Conway’s Game of Life, a famous cellular automaton. For those unfamiliar with the “Game,” imagine each lit LED is a cell in a Petri dish. If a cell has too few or too many neighbors, it dies out. If an empty space has exactly three living neighbors, a new cell appears there. When these rules have been applied to all of the spaces on the grid, a new “generation” begins and the rules are reapplied. This pattern can continue indefinitely, given the right conditions. In my demo, a random array of lit and unlit LEDs constitutes the starting pattern; then the automaton runs for a given number of iterations.

GameOfLifePi[sh_DeviceObject, rounds_Integer, pause_Real,     color_List] :=    Module[{GameOfLife, StartingImage, images},     GameOfLife = {224, {2, {{2, 2, 2}, {2, 1, 2}, {2, 2, 2}}}, {1, 1}};    StartingImage = RandomInteger[{0, 1}, {8, 8}];    images = # & /@       CellularAutomaton[GameOfLife, StartingImage, rounds];    (DeviceWrite[sh, {#, "Color" \[RightArrow] color}];       Pause[pause]) & /@ images;];

GameOfLifePi[hat, 25, 0.5, {128, 128, 128}];

The rounds, pause and color parameters can all be modified to change how the automaton is displayed and how long Mathematica waits before displaying the next iteration.

These demos give a taste of what is possible when Mathematica connects with the Sense HAT. Have a look yourself at the Sense HAT documentation page, and send a note to Wolfram Community if you come up with something interesting!

Download this post as a Computable Document Format (CDF) file. New to CDF? Get your copy for free with this one-time download.

http://blog.wolfram.com/2017/04/27/using-the-sense-hat-on-a-raspberry-pi-with-mathematica-11/feed/ 0
Join Us for the Computation Meets Data Science Conference in London, 11 May http://blog.wolfram.com/2017/04/26/join-us-for-the-computation-meets-data-science-conference-in-london-11-may/ http://blog.wolfram.com/2017/04/26/join-us-for-the-computation-meets-data-science-conference-in-london-11-may/#comments Wed, 26 Apr 2017 08:00:03 +0000 Lois Jamieson http://blog.internal.wolfram.com/?p=36105 Data Science Conference

With the world of data science developing at a rapid pace and companies increasingly aware of its importance, Wolfram is pleased to bring together a range of data science experts at the Computation Meets Data Science Conference on 11 May, in partnership with the Satellite Applications Catapult and Digital Catapult.

Over recent years, Wolfram has been a leading force in revolutionising the field of data science, whether through the development of advanced computation technologies or through the creation of bespoke customer solutions. Wolfram developers have a wealth of knowledge for building your data science strategy, implementing the appropriate infrastructure and transforming traditional methodologies with improved automated solutions. Drawing on this expertise, we have brought together a variety of data science and technology specialists to share their knowledge and experience with you, and to provide an opportunity to quiz the experts on your data science challenges.

We’ve organised a jam-packed schedule, starting with opening remarks from Conrad Wolfram, followed by guest talks, interactive sessions and networking breaks. The conference has a little bit of something for everyone, with panel sessions covering the creation of a data science infrastructure, using data science to promote cultural change, and practical use cases of how computation has changed different organisations’ outlook on data.

To give a flavour of some of the specialist sessions we have lined up, speakers will include:

  • Keith Harrison, Head of Knowledge Management at the Offshore Renewable Energy Catapult
  • Alison Lowndes, Artificial Intelligence Developer Relations at NVIDIA
  • Marco Thiel, Professor of Mathematics and Physics at the University of Aberdeen
  • Fredrik Döberl, Owner and Founder of Ablona AB

Please visit the conference website for more information or to register.

http://blog.wolfram.com/2017/04/26/join-us-for-the-computation-meets-data-science-conference-in-london-11-may/feed/ 0
Launching the Wolfram Data Repository: Data Publishing that Really Works http://blog.wolfram.com/2017/04/20/launching-the-wolfram-data-repository-data-publishing-that-really-works/ http://blog.wolfram.com/2017/04/20/launching-the-wolfram-data-repository-data-publishing-that-really-works/#comments Thu, 20 Apr 2017 16:04:25 +0000 Stephen Wolfram http://blog.internal.wolfram.com/?p=36077 After a Decade, It’s Finally Here!

I’m pleased to announce that as of today, the Wolfram Data Repository is officially launched! It’s been a long road. I actually initiated the project a decade ago—but it’s only now, with all sorts of innovations in the Wolfram Language and its symbolic ways of representing data, as well as with the arrival of the Wolfram Cloud, that all the pieces are finally in place to make a true computable data repository that works the way I think it should.

Wolfram Data Respository

It’s happened to me a zillion times: I’m reading a paper or something, and I come across an interesting table or plot. And I think to myself: “I’d really like to get the data behind that, to try some things out”. But how can I get the data?

If I’m lucky there’ll be a link somewhere in the paper. But it’s usually a frustrating experience to follow it. Because even if there’s data there (and often there actually isn’t), it’s almost never in a form where one can readily use it. It’s usually quite raw—and often hard to decode, and perhaps even intertwined with text. And even if I can see the data I want, I almost always find myself threading my way through footnotes to figure out what’s going on with it. And in the end I usually just decide it’s too much trouble to actually pull out the data I want.

And I suppose one might think that this is just par for the course in working with data. But in modern times, we have a great counterexample: the Wolfram Language. It’s been one of my goals with the Wolfram Language to build into it as much data as possible—and make all of that data immediately usable and computable. And I have to say that it’s worked out great. Whether you need the mass of Jupiter, or the masses of all known exoplanets, or Alan Turing’s date of birth—or a trillion much more obscure things—you just ask for them in the language, and you’ll get them in a form where you can immediately compute with them.

Here’s the mass of Jupiter (and, yes, one can use “Wolfram|Alpha-style” natural language to ask for it):


Dividing it by the mass of the Earth immediately works:

Entity["Planet", "Jupiter"]["Mass"]/Entity["Planet", "Earth"]["Mass"]

Here’s a histogram of the masses of known exoplanets, divided by the mass of Jupiter:

Histogram[  EntityClass["Exoplanet", All]["Mass"]/   Entity["Planet", "Jupiter"]["Mass"]]

And here, for good measure, is Alan Turing’s date of birth, in an immediately computable form:

Alan Turing(person)["BirthDate"]

Of course, it’s taken many years and lots of work to make everything this smooth, and to get to the point where all those thousands of different kinds of data are fully integrated into the Wolfram Language—and Wolfram|Alpha.

But what about other data—say data from some new study or experiment? It’s easy to upload it someplace in some raw form. But the challenge is to make the data actually useful.

And that’s where the new Wolfram Data Repository comes in. Its idea is to leverage everything we’ve done with the Wolfram Language—and Wolfram|Alpha, and the Wolfram Cloud—to make it as easy as possible to make data as broadly usable and computable as possible.

There are many parts to this. But let me state our basic goal. I want it to be the case that if someone is dealing with data they understand well, then they should be able to prepare that data for the Wolfram Data Repository in as little as 30 minutes—and then have that data be something that other people can readily use and compute with.

It’s important to set expectations. Making data fully computable—to the standard of what’s built into the Wolfram Language—is extremely hard. But there’s a lower standard that still makes data extremely useful for many purposes. And what’s important about the Wolfram Data Repository (and the technology around it) is it now makes that standard easy to achieve—with the result that it’s now practical to publish data in a form that can really be used by many people.

An Example

Each item published in the Wolfram Data Repository gets its own webpage. Here, for example, is the page for a public dataset about meteorite landings:

Meteorite Landings

At the top is some general information about the dataset. But then there’s a piece of a Wolfram Notebook illustrating how to use the dataset in the Wolfram Language. And by looking at this notebook, one can start to see some of the real power of the Wolfram Data Repository.

One thing to notice is that it’s very easy to get the data. All you do is ask for ResourceData["Meteorite Landings"]. And whether you’re using the Wolfram Language on a desktop or in the cloud, this will give you a nice symbolic representation of data about 45716 meteorite landings (and, yes, the data is carefully cached so this is as fast as possible, etc.):

And then the important thing is that you can immediately start to do whatever computation you want on that dataset. As an example, this takes the "Coordinates" element from all rows, then takes a random sample of 1000 results, and geo plots them:

GeoListPlot[RandomSample[ResourceData["Meteorite Landings"][All, "Coordinates"],1000]]

Many things have to come together for this to work. First, the data has to be reliably accessible—as it is in the Wolfram Cloud. Second, one has to be able to tell where the coordinates are—which is easy if one can see the dataset in a Wolfram Notebook. And finally, the coordinates have to be in a form in which they can immediately be computed with.

This last point is critical. Just storing the textual form of a coordinate—as one might in something like a spreadsheet—isn’t good enough. One has to have it in a computable form. And needless to say, the Wolfram Language has such a form for geo coordinates: the symbolic construct GeoPosition[{lat,lon}].

There are other things one can immediately see from the meteorites dataset too. Like notice there’s a "Mass" column. And because we’re using the Wolfram Language, masses don’t have to just be numbers; they can be symbolic Quantity objects that correctly include their units. There’s also a "Year" column in the data, and again, each year is represented by an actual, computable, symbolic DateObject construct.

There are lots of different kinds of possible data, and one needs a sophisticated data ontology to handle them. But that’s exactly what we’ve built for the Wolfram Language, and for Wolfram|Alpha, and it’s now been very thoroughly tested. It involves 10,000 kinds of units, and tens of millions of “core entities”, like cities and chemicals and so on. We call it the Wolfram Data Framework (WDF)—and it’s one of the things that makes the Wolfram Data Repository possible.

What’s in the Wolfram Data Repository So Far?

Today is the initial launch of the Wolfram Data Repository, and to get ready for this launch we’ve been adding sample content to the repository for several months. Some of what we’ve added are “obvious” famous datasets. Some are datasets that we found for some reason interesting, or curious. And some are datasets that we created ourselves—and in some cases that I created myself, for example, in the course of writing my book A New Kind of Science.

WDR Home Page Categories

There’s plenty already in the Wolfram Data Repository that’ll immediately be useful in a variety of applications. But in a sense what’s there now is just an example of what can be there—and the kinds of things we hope and expect will be contributed by many other people and organizations.

The fact that the Wolfram Data Repository is built on top of our Wolfram Language technology stack immediately gives it great generality—and means that it can handle data of any kind. It’s not just tables of numerical data as one might have in a spreadsheet or simple database. It’s data of any type and structure, in any possible combination or arrangement.

Home Page Types

There are time series:

Take[ResourceData["US Federal Outlays by Agency"], 3]

There are training sets for machine learning:

RandomSample[ResourceData["MNIST"], 30]

There’s gridded data:

ResourceData["GMM-3 Mars Gravity Map"]

There’s the text of many books:

WordCloud[ResourceData["On the Origin of Species"]]

There’s geospatial data:

ResourceData["Global Air Navigation Aids"]

GeoHistogram[ResourceData"Global Air Navigation Aids"][All, "Geoposition"], 50, GeoRange-> United States]

Many of the data resources currently in the Wolfram Data Repository are quite tabular in nature. But unlike traditional spreadsheets or tables in databases, they’re not restricted to having just one level of rows and columns—because they’re represented using symbolic Wolfram Language Dataset constructs, which can handle arbitrarily ragged structures, of any depth.

ResourceData["Sample Data: Solar System Planets and Moons"]

But what about data that normally lives in relational or graph databases? Well, there’s a construct called EntityStore that was recently added to the Wolfram Language. We’ve actually been using something like it for years inside Wolfram|Alpha. But what EntityStore now does is to let you set up arbitrary networks of entities, properties and values, right in the Wolfram Language. It typically takes more curation than setting up something like a Dataset—but the result is a very convenient representation of knowledge, on which all the same functions can be used as with built-in Wolfram Language knowledge.

Here’s a data resource that’s an entity store:

ResourceData ["Museum of Modern Art Holdings and Artists"]

This adds the entity stores to the list of entity stores to be used automatically:

PrependTo [$EntityStores, %];

Now here are 5 random entities of type "MoMAArtist" from the entity store:

RandomEntity ["MoMAArtist", 5]

For each artist, one can extract a dataset of values:

Entity[MoMAArtist], Otto Mühl[Dataset]

This queries the entity store to find artists with the most recent birth dates:

EntityList[Entity["MoMAArtist", "BirthDate" -> TakeLargest[5]]]

How It Works

The Wolfram Data Repository is built on top of a new, very general thing in the Wolfram Language called the “resource system”. (Yes, expect all sorts of other repository and marketplace-like things to be rolling out shortly.)

The resource system has “resource objects”, that are stored in the cloud (using CloudObject), then automatically downloaded and cached on the desktop if necessary (using LocalObject). Each ResourceObject contains both primary content and metadata. For the Wolfram Data Repository, the primary content is data, which you can access using ResourceData.


The Wolfram Data Repository that we’re launching today is a public resource, that lives in the public Wolfram Cloud. But we’re also going to be rolling out private Wolfram Data Repositories, that can be run in Enterprise Private Clouds—and indeed inside our own company we’ve already set up several private data repositories, that contain internal data for our company.

There’s no limit in principle on the size of the data that can be stored in the Wolfram Data Repository. But for now, the “plumbing” is optimized for data that’s at most about a few gigabytes in size—and indeed the existing examples in the Wolfram Data Repository make it clear that an awful lot of useful data never even gets bigger than a few megabytes in size.

The Wolfram Data Repository is primarily intended for the case of definitive data that’s not continually changing. For data that’s constantly flowing in—say from IoT devices—we released last year the Wolfram Data Drop. Both Data Repository and Data Drop are deeply integrated into the Wolfram Language, and through our resource system, there’ll be some variants and combinations coming in the future.

Delivering Data to the World

Our goal with the Wolfram Data Repository is to provide a central place for data from all sorts of organizations to live—in such a way that it can readily be found and used.

Each entry in the Wolfram Data Repository has an associated webpage, which describes the data it contains, and gives examples that can immediately be run in the Wolfram Cloud (or downloaded to the desktop).

Open in Cloud

On the webpage for each repository entry (and in the ResourceObject that represents it), there’s also metadata, for indexing and searching—including standard Dublin Core bibliographic data. To make it easier to refer to the Wolfram Data Repository entries, every entry also has a unique DOI.

The way we’re managing the Wolfram Data Repository, every entry also has a unique readable registered name, that’s used both for the URL of its webpage, and for the specification of the ResourceObject that represents the entry.

It’s extremely easy to use data from the Wolfram Data Repository inside a Wolfram Notebook, or indeed in any Wolfram Language program. The data is ultimately stored in the Wolfram Cloud. But you can always download it—for example right from the webpage for any repository entry.

The richest and most useful form in which to get the data is the Wolfram Language or the Wolfram Data Framework (WDF)—either in ASCII or in binary. But we’re also setting it up so you can download in other formats, like JSON (and in suitable cases CSV, TXT, PNG, etc.) just by pressing a button.

Data Downloads

Of course, even formats like JSON don’t have native ways to represent entities, or quantities with units, or dates, or geo positions—or all those other things that WDF and the Wolfram Data Repository deal with. So if you really want to handle data in its full form, it’s much better to work directly in the Wolfram Language. But then with the Wolfram Language you can always process some slice of the data into some simpler form that does makes sense to export in a lower-level format.

How Contributions Work

The Wolfram Data Repository as we’re releasing it today is a platform for publishing data to the world. And to get it started, we’ve put in about 500 sample entries. But starting today we’re accepting contributions from anyone. We’re going to review and vet contributions much like we’ve done for the past decade for the Wolfram Demonstrations Project. And we’re going to emphasize contributions and data that we feel are of general interest.

But the technology of the Wolfram Data Repository—and the resource system that underlies it—is quite general, and allows people not just to publish data freely to the world, but also to share data in a more controlled fashion. The way it works is that people prepare their data just like they would for submission to the public Wolfram Data Repository. But then instead of actually submitting it, they just deploy it to their own Wolfram Cloud accounts, giving access to whomever they want.

And in fact, the general workflow is that even when people are submitting to the public Wolfram Data Repository, we’re going to expect them to have first deployed their data to their own Wolfram Cloud accounts. And as soon as they do that, they’ll get webpages and everything—just like in the public Wolfram Data Repository.

OK, so how does one create a repository entry? You can either do it programmatically using Wolfram Language code, or do it more interactively using Wolfram Notebooks. Let’s talk about the notebook way first.

You start by getting a template notebook. You can either do this through the menu item File > New > Data Resource, or you can use CreateNotebook["DataResource"]. Either way, you’ll get something that looks like this:

Data Resource Construction Notebook

Basically it’s then a question of “filling out the form”. A very important section is the one that actually provides the content for the resource:

Resource Content

Yes, it’s Wolfram Language code—and what’s nice is that it’s flexible enough to allow for basically any content you want. You can either just enter the content directly in the notebook, or you can have the notebook refer to a local file, or to a cloud object you have.

An important part of the Construction Notebook (at least if you want to have a nice webpage for your data) is the section that lets you give examples. When the examples are actually put up on the webpage, they’ll reference the data resource you’re creating. But when you’re filling in the Construction Notebook the resource hasn’t been created yet. The symbolic character of the Wolfram Language comes to the rescue, though. Because it lets you reference the content of the data resource symbolically as $$Data in the inputs that’ll be displayed, but lets you set $$Data to actual data when you’re working in the Construction Notebook to build up the examples.

Heart Rate Data

Alright, so once you’ve filled out the Construction Notebook, what do you do? There are two initial choices: set up the resource locally on your computer, or set it up in the cloud:

Private Deploy

And then, if you’re ready, you can actually submit your resource for publication in the public Wolfram Data Repository (yes, you need to get a Publisher ID, so your resource can be associated with your organization rather than just with your personal account):

Submit to the Wolfram Data Repository Page

It’s often convenient to set up resources in notebooks. But like everything else in our technology stack, there’s a programmatic Wolfram Language way to do it too—and sometimes this is what will be best.

Remember that everything that is going to be in the Wolfram Data Repository is ultimately a ResourceObject. And a ResourceObject—like everything else in the Wolfram Language—is just a symbolic expression, which happens to contain an association that gives the content and metadata of the resource object.

Well, once you’ve created an appropriate ResourceObject, you can just deploy it to the cloud using CloudDeploy. And when you do this, a private webpage associated with your cloud account will automatically be created. That webpage will in turn correspond to a CloudObject. And by setting the permissions of that cloud object, you can determine who will be able to look at the webpage, and who will be able to get the data that’s associated with it.

When you’ve got a ResourceObject, you can submit it to the public Wolfram Data Repository just by using ResourceSubmit.

By the way, all this stuff works not just for the main Wolfram Data Repository in the public Wolfram Cloud, but also for data repositories in private clouds. The administrator of an Enterprise Private Cloud can decide how they want to vet data resources that are submitted (and how they want to manage things like name collisions)—though often they may choose just to publish any resource that’s submitted.

The procedure we’ve designed for vetting and editing resources for the public Wolfram Data Repository is quite elaborate—though in any given case we expect it to run quickly. It involves doing automated tests on the incoming data and examples—and then ensuring that these continue working as changes are made, for example in subsequent versions of the Wolfram Language. Administrators of private clouds definitely don’t have to use this procedure—but we’ll be making our tools available if they want to.

Making a Data-Backed Publication

OK, so let’s say there’s a data resource in the Wolfram Data Repository. How can it actually be used to create a data-backed publication? The most obvious answer is just for the publication to include a link to the webpage for the data resource in the Wolfram Data Repository. And once people go to the page, it immediately shows them how to access the data in the Wolfram Language, use it in the Wolfram Open Cloud, download it, or whatever.

But what about an actual visualization or whatever that appears in the paper? How can people know how to make it? One possibility is that the visualization can just be included among the examples on the webpage for the data resource. But there’s also a more direct way, which uses Source Links in the Wolfram Cloud.

Here’s how it works. You create a Wolfram Notebook that takes data from the Wolfram Data Repository and creates the visualization:

Creating Visualizations with a Wolfram Notebook

Then you deploy this visualization to the Wolfram Cloud—either using Wolfram Language functions like CloudDeploy and EmbedCode, or using menu items. But when you do the deployment, you say to include a source link (SourceLink->Automatic in the Wolfram Language). And this means that when you get an embeddable graphic, it comes with a source link that takes you back to the notebook that made the graphic:

Sourcelink to the Notebook

So if someone is reading along and they get to that graphic, they can just follow its source link to see how it was made, and to see how it accesses data from the Wolfram Data Repository. With the Wolfram Data Repository you can do data-backed publishing; with source links you can also do full notebook-backed publishing.

The Big Win

Now that we’ve talked a bit about how the Wolfram Data Repository works, let’s talk again about why it’s important—and why having data in it is so valuable.

The #1 reason is simple: it makes data immediately useful, and computable.

There’s nice, easy access to the data (just use ResourceData["..."]). But the really important—and unique—thing is that data in the Wolfram Data Repository is stored in a uniform, symbolic way, as WDF, leveraging everything we’ve done with data over the course of so many years in the Wolfram Language and Wolfram|Alpha.

Why is it good to have data in WDF? First, because in WDF the meaning of everything is explicit: whether it’s an entity, or quantity, or geo position, or whatever, it’s a symbolic element that’s been carefully designed and documented. (And it’s not just a disembodied collection of numbers or strings.) And there’s another important thing: data in WDF is already in precisely the form it’s needed for one to be able to immediately visualize, analyze or otherwise compute with it using any of the many thousands of functions that are built into the Wolfram Language.

Wolfram Notebooks are also an important part of the picture—because they make it easy to show how to work with the data, and give immediately runnable examples. Also critical is the fact that the Wolfram Language is so succinct and easy to read—because that’s what makes it possible to give standalone examples that people can readily understand, modify and incorporate into their own work.

In many cases using the Wolfram Data Repository will consist of identifying some data resource (say through a link from a document), then using the Wolfram Language in Wolfram Notebooks to explore the data in it. But the Wolfram Data Repository is fully integrated into the Wolfram Language, so it can be used wherever the language is used. Which means the data from the Wolfram Data Repository can be used not just in the cloud or on the desktop, but also in servers and so on. And, for example, it can also be used in APIs or scheduled tasks, using the exact same ResourceData functions as ever.

The most common way the Wolfram Data Repository will be used is one resource at a time. But what’s really great about the uniformity and standardization that WDF provides is that it allows different data resources to be used together: those dates or geo positions mean the same thing even in different data resources, so they can immediately be put together in the same analysis, visualization, or whatever.

The Wolfram Data Repository builds on the whole technology stack that we’ve been assembling for the past three decades. In some ways it’s just a sophisticated piece of infrastructure that makes a lot of things easier to do. But I can already tell that its implications go far beyond that—and that it’s going to have a qualitative effect on the extent to which people can successfully share and reuse a wide range of kinds of data.

The Process of Data Curation

It’s a big win to have data in the Wolfram Data Repository. But what’s involved in getting it there? There’s almost always a certain amount of data curation required.

Let’s take a look again at the meteorite landings dataset I showed earlier in this post. It started from a collection of data made available in a nicely organized way by NASA. (Quite often one has to scrape webpages or PDFs; this is a case where the data happens to be set up to be downloadable in a variety of convenient formats.)

Meteorite Landing Data from NASA

As is fairly typical, the basic elements of the data here are numbers and strings. So the first thing to do is to figure out how to map these to meaningful symbolic constructs in WDF. For example, the “mass” column is labeled as being “(g)”, i.e. in grams—so each element in it should get converted to Quantity[value,"Grams"]. It’s a little trickier, though, because for some rows—corresponding to some meteorites—the value is just blank, presumably because it isn’t known.

So how should that be represented? Well, because the Wolfram Language is symbolic it’s pretty easy. And in fact there’s a standard symbolic construct Missing[...] for indicating missing data, which is handled consistently in analysis and visualization functions.

As we start to look further into the dataset, we see all sorts of other things. There’s a column labeled “year”. OK, we can convert that into DateObject[{value}]—though we need to be careful about any BC dates (how would they appear in the raw data?).

Next there are columns “reclat” and “reclong”, as well as a column called “GeoLocation” that seems to combine these, but with numbers quoted a different precision. A little bit of searching suggests that we should just take reclat and reclong as the latitude and longitude of the meteorite—then convert these into the symbolic form GeoPosition[{lat,lon}].

To do this in practice, we’d start by just importing all the data:

Import ["https://data.nasa.gov/api/views/gh4g-9sfh/rows.csv?accessType=\ DOWNLOAD", "CSV"]

OK, let’s extract a sample row:

data [[2]]

Already there’s something unexpected: the date isn’t just the year, but instead it’s a precise time. So this needs to be converted:

Interpreter ["DateTime"][data[[2, 7]]]

Now we’ve got to reset this to correspond only to a date at a granularity of a year:

DateObject [{DateValue[Interpreter["DateTime"][data[[2, 7]]],     "Year"]}, "Year"]

Here is the geo position:

GeoPosition [{data[[2, -3]], data[[2, -2]]}]" title="GeoPosition[{data[[2, -3]], data[[2, -2]]}]

And we can keep going, gradually building up code that can be applied to each row of the imported data. In practice there are often little things that go wrong. There’s something missing in some row. There’s an extra piece of text (a “footnote”) somewhere. There’s something in the data that got misinterpreted as a delimiter when the data was provided for download. Each one of these needs to be handled—preferably with as much automation as possible.

But in the end we have a big list of rows, each of which needs to be assembled into an association, then all combined to make a Dataset object that can be checked to see if it’s good to go into the Wolfram Data Repository.

The Data Curation Hierarchy

The example above is fairly typical of basic curation that can be done in less than 30 minutes by any decently skilled user of the Wolfram Language. (A person who’s absorbed my book An Elementary Introduction to the Wolfram Language should, for example, be able to do it.)

It’s a fairly simple example—where notably the original form of the data was fairly clean. But even in this case it’s worth understanding what hasn’t been done. For example, look at the column labeled "Classification" in the final dataset. It’s got a bunch of strings in it. And, yes, we can do something like make a word cloud of these strings:

WordCloud [  Normal[ResourceData["Meteorite Landings"][All, "Classification"]]]

But to really make these values computable, we’d have to do more work. We’d have to figure out some kind of symbolic representation for meteorite classification, then we’d have to do curation (and undoubtedly ask some meteorite experts) to fit everything nicely into that representation. The advantage of doing this is that we could then ask questions about those values (“what meteorites are above L3?”), and expect to compute answers. But there’s plenty we can already do with this data resource without that.

My experience in general has been that there’s a definite hierarchy of effort and payoff in getting data to be computable at different levels—starting with the data just existing in digital form, and ending with the data being cleanly computable enough that it can be fully integrated in the core Wolfram Language, and used for repeated, systematic computations.

Data Hierarchy Levels


Let’s talk about this hierarchy a bit.

The zeroth thing, of course, is that the data has to exist. And the next thing is that it has to be in digital form. If it started on handwritten index cards, for example, it had better have been entered into a document or spreadsheet or something.

But then the next issue is: how are people supposed to get access to that document or spreadsheet? Well, a good answer is that it should be in some kind of accessible cloud—perhaps referenced with a definite URI. And for a lot of data repositories that exist out there, just making the data accessible like this is the end of the story.

But one has to go a lot further to make the data actually useful. The next step is typically to make sure that the data is arranged in some definite structure. It might be a set of rows and columns, or it might be something more elaborate, and, say, hierarchical. But the point is to have a definite, known structure.

In the Wolfram Language, it’s typically trivial to take data that’s stored in any reasonable format, and use Import to get it into the Wolfram Language, arranged in some appropriate way. (As I’ll talk about later, it might be a Dataset, it might be an EntityStore, it might just be a list of Image objects, or it might be all sorts of other things.)

But, OK, now things start getting more difficult. We need to be able to recognize, say, that such-and-such a column has entries representing countries, or pairs of dates, or animal species, or whatever. SemanticImport uses machine learning and does a decent job of automatically importing many kinds of data. But there are often things that have to be fixed. How exactly is missing data represented? Are there extra annotations that get in the way of automatic interpretation? This is where one starts needing experts, who really understand the data.

But let’s say one’s got through this stage. Well, then in my experience, the best thing to do is to start visualizing the data. And very often one will immediately see things that are horribly wrong. Some particular quantity was represented in several inconsistent ways in the data. Maybe there was some obvious transcription or other error. And so on. But with luck it’s fairly easy to transform the data to handle the obvious issues—though to actually get it right almost always requires someone who is an expert on the data.

What comes out of this process is typically very useful for many purposes—and it’s the level of curation that we’re expecting for things submitted to the Wolfram Data Repository.

It’ll be possible to do all sorts of analysis and visualization and other things with data in this form.

But if one wants, for example, to actually integrate the data into Wolfram|Alpha, there’s considerably more that has to be done. For a start, everything that can realistically be represented symbolically has to be represented symbolically. It’s not good enough to have random strings giving values of things—because one can’t ask systematic questions about those. And this typically requires inventing systematic ways to represent new kinds of concepts in the world—like the "Classification" for meteorites.

Wolfram|Alpha works by taking natural language input. So the next issue is: when there’s something in the data that can be referred to, how do people refer to it in natural language? Often there’ll be a whole collection of names for something, with all sorts of variations. One has to algorithmically capture all of the possibilities.

Next, one has to think about what kinds of questions will be asked about the data. In Wolfram|Alpha, the fact that the questions get asked in natural language forces a certain kind of simplicity on them. But it makes one also need to figure out just what the linguistics of the questions can be (and typically this is much more complicated than the linguistics for entities or other definite things). And then—and this is often a very difficult part—one has to figure out what people want to compute, and how they want to compute it.

At least in the world of Wolfram|Alpha, it turns out to be quite rare for people just to ask for raw pieces of data. They want answers to questions—that have to be computed with models, or methods, or algorithms, from the underlying data. For meteorites, they might want to know not the raw information about when a meteorite fell, but compute the weathering of the meteorite, based on when it fell, what climate it’s in, what it’s made of, and so on. And to have data successfully be integrated into Wolfram|Alpha, those kinds of computations all need to be there.

For full Wolfram|Alpha there’s even more. Not only does one have to be able to give a single answer, one has to be able to generate a whole report, that includes related answers, and presents them in a well-organized way.

It’s ultimately a lot of work. There are very few domains that have been added to Wolfram|Alpha with less than a few skilled person-months of work. And there are plenty of domains that have taken person-years or tens of person-years. And to get the right answers, there always has to be a domain expert involved.

Getting data integrated into Wolfram|Alpha is a significant achievement. But there’s further one can go—and indeed to integrate data into the Wolfram Language one has to go further. In Wolfram|Alpha people are asking one-off questions—and the goal is to do as well as possible on individual questions. But if there’s data in the Wolfram Language, people won’t just ask one-off questions with it: they’ll also do large-scale systematic computations. And this demands a much greater level of consistency and completeness—which in my experience rarely takes less than person-years per domain to achieve.

But OK. So where does this leave the Wolfram Data Repository? Well, the good news is that all that work we’ve put into Wolfram|Alpha and the Wolfram Language can be leveraged for the Wolfram Data Repository. It would take huge amounts of work to achieve what’s needed to actually integrate data into Wolfram|Alpha or the Wolfram Language. But given all the technology we have, it takes very modest amounts of work to make data already very useful. And that’s what the Wolfram Data Repository is about.

The Data Publishing Ecosystem

With the Wolfram Data Repository (and Wolfram Notebooks) there’s finally a great way to do true data-backed publishing—and to ensure that data can be made available in an immediately useful and computable way.

For at least a decade there’s been lots of interest in sharing data in areas like research and government. And there’ve been all sorts of data repositories created—often with good software engineering—with the result that instead of data just sitting on someone’s local computer, it’s now pretty common for it to be uploaded to a central server or cloud location.

But the problem has been that the data in these repositories is almost always in a quite raw form—and not set up to be generally meaningful and computable. And in the past—except in very specific domains—there’s been no really good way to do this, at least in any generality. But the point of the Wolfram Data Repository is to use all the development we’ve done on the Wolfram Language and WDF to finally be able to provide a framework for having data in an immediately computable form.

The effect is dramatic. One goes from a situation where people are routinely getting frustrated trying to make use of data to one in which data is immediately and readily usable. Often there’s been lots of investment and years of painstaking work put into accumulating some particular set of data. And it’s often sad to see how little the data actually gets used—even though it’s in principle accessible to anyone. But I’m hoping that the Wolfram Data Repository will provide a way to change this—by allowing data not just to be accessible, but also computable, and easy for anyone to immediately and routinely use as part of their work.

There’s great value to having data be computable—but there’s also some cost to making it so. Of course, if one’s just collecting the data now, and particularly if it’s coming from automated sources, like networks of sensors, then one can just set it up to be in nice, computable WDF right from the start (say by using the data semantics layer of the Wolfram Data Drop). But at least for a while there’s going to still be a lot of data that’s in the form of things like spreadsheets and traditional databases—-that don’t even have the technology to support the kinds of structures one would need to directly represent WDF and computable data.

So that means that there’ll inevitably have to be some effort put into curating the data to make it computable. Of course, with everything that’s now in the Wolfram Language, the level of tools available for curation has become extremely high. But to do curation properly, there’s always some level of human effort—and some expert input—that’s required. And a key question in understanding the post-Wolfram-Data-Repository data publishing ecosystem is who is actually going to do this work.

In a first approximation, it could be the original producers of the data—or it could be professional or other “curation specialists”—or some combination. There are advantages and disadvantages to all of these possibilities. But I suspect that at least for things like research data it’ll be most efficient to start with the original producers of the data.

The situation now with data curation is a little similar to the historical situation with document production. Back when I was first doing science (yes, in the 1970s) people handwrote papers, then gave them to professional typists to type. Once typed, papers would be submitted to publishers, who would then get professional copyeditors to copyedit them, and typesetters to typeset them for printing. It was all quite time consuming and expensive. But over the course of the 1980s, authors began to learn to type their own papers on a computer—and then started just uploading them directly to servers, in effect putting them immediately in publishable form.

It’s not a perfect analogy, but in both data curation and document editing there are issues of structure and formatting—and then there are issues that require actual understanding of the content. (Sometimes there are also more global “policy” issues too.) And for producing computable data, as for producing documents, almost always the most efficient thing will be to start with authors “typing their own papers”—or in the case of data, putting their data into WDF themselves.

Of course, to do this requires learning at least a little about computable data, and about how to do curation. And to assist with this we’re working with various groups to develop materials and provide training about such things. Part of what has to be communicated is about mechanics: how to move data, convert formats, and so on. But part of it is also about principles—and about how to make the best judgement calls in setting up data that’s computable.

We’re planning to organize “curateathons” where people who know the Wolfram Language and have experience with WDF data curation can pair up with people who understand particular datasets—and hopefully quickly get all sorts of data that they may have accumulated over decades into computable form—and into the Wolfram Data Repository.

In the end I’m confident that a very wide range of people (not just techies, but also humanities people and so on) will be able to become proficient at data curation with the Wolfram Language. But I expect there’ll always be a certain mixture of “type it yourself” and “have someone type it for you” approaches to data curation. Some people will make their data computable themselves—or will have someone right there in their lab or whatever who does. And some people will instead rely on outside providers to do it.

Who will these providers be? There’ll be individuals or companies set up much like the ones who provide editing and publishing services today. And to support this we’re planning a “Certified Data Curator” program to help define consistent standards for people who will work with the originators of a wide range of different kinds of data putting it into computable form.

But in additional to individuals or specific “curation companies”, there are at least two other kinds of entities that have the potential to be major facilitators of making data computable.

The first is research libraries. The role of libraries at many universities is somewhat in flux these days. But something potentially very important for them to do is to provide a central place for organizing—and making computable—data from the university and beyond. And in many ways this is just a modern analog of traditional library activities like archiving and cataloging.

It might involve the library actually having a private cloud version of the Wolfram Data Repository—and it might involve the library having its own staff to do curation. Or it might just involve the library providing advice. But I’ve found there’s quite a bit of enthusiasm in the library community for this kind of direction (and it’s perhaps an interesting sign that at our company people involved in data curation have often originally been trained in library science).

In addition to libraries, another type of organization that should be involved in making data computable is publishing companies. Some might say that publishing companies have had it a bit easy in the last couple of decades. Back in the day, every paper they published involved all sorts of production work, taking it from manuscript to final typeset version. But for years now, authors have been delivering their papers in digital forms that publishers don’t have to do much work on.

With data, though, there’s again something for publishers to do, and again a place for them to potentially add great value. Authors can pretty much put raw data into public repositories for themselves. But what would make publishers visibly add value is for them to process (or “edit”) the data—putting in the work to make it computable. The investment and processes will be quite similar to what was involved on the text side in the past—it’s just that now instead of learning about phototypesetting systems, publishers should be learning about WDF and the Wolfram Language.

It’s worth saying that as of today all data that we accept into the Wolfram Data Repository is being made freely available. But we’re anticipating in the near future we’ll also incorporate a marketplace in which data can be bought and sold (and even potentially have meaningful DRM, at least if it’s restricted to being used in the Wolfram Language). It’ll also be possible to have a private cloud version of the Wolfram Data Repository—in which whatever organization that runs it can set up whatever rules it wants about contributions, subscriptions and access.

One feature of traditional paper publishing is the sense of permanence it provides: once even just a few hundred printed copies of a paper are on shelves in university libraries around the world, it’s reasonable to assume that the paper is going to be preserved forever. With digital material, preservation is more complicated.

If someone just deploys a data resource to their Wolfram Cloud account, then it can be available to the world—but only so long as the account is maintained. The Wolfram Data Repository, though, is intended to be something much more permanent. Once we’ve accepted a piece of data for the repository, our goal is to ensure that it’ll continue to be available, come what may. It’s an interesting question how best to achieve that, given all sorts of possible future scenarios in the world. But now that the Wolfram Data Repository is finally launched, we’re going to be working with several well-known organizations to make sure that its content is as securely maintained as possible.

Data-Backed Journals

The Wolfram Data Repository—and private versions of it—is basically a powerful, enabling technology for making data available in computable form. And sometimes all one wants to do is to make the data available.

But at least in academic publishing, the main point usually isn’t the data. There’s usually a “story to be told”—and the data is just backup for that story. Of course, having that data backing is really important—and potentially quite transformative. Because when one has the data, in computable form, it’s realistic for people to work with it themselves, reproducing or checking the research, and directly building on it themselves.

But, OK, how does the Wolfram Data Repository relate to traditional academic publishing? For our official Wolfram Data Repository we’re going to have definite standards for what we accept—and we’re going to concentrate on data that we think is of general interest or use. We have a whole process for checking the structure of data, and applying software quality assurance methods, as well as expert review, to it.

And, yes, each entry in the Wolfram Data Repository gets a DOI, just like a journal article. But for our official Wolfram Data Repository we’re focused on data—and not the story around it. We don’t see it as our role to check the methods by which the data was obtained, or to decide whether conclusions drawn from it are valid or not.

But given the Wolfram Data Repository, there are lots of new opportunities for data-backed academic journals that do in effect “tell stories”, but now have the infrastructure to back them up with data that can readily be used.

I’m looking forward, for example, to finally making the journal Complex Systems that I founded 30 years ago a true data-backed journal. And there are many existing journals where it makes sense to use versions of the Wolfram Data Repository (often in a private cloud) to deliver computable data associated with journal articles.

But what’s also interesting is that now that one can take computable data for granted, there’s a whole new generation of “Journal of Data-Backed ____” journals that become possible—that not only use data from the Wolfram Data Repository, but also actually present their results as Wolfram Notebooks that can immediately be rerun and extended (and can also, for example, contain interactive elements).

The Corporate Version

I’ve been talking about the Wolfram Data Repository in the context of things like academic journals. But it’s also important in corporate settings. Because it gives a very clean way to have data shared across an organization (or shared with customers, etc.).

Typically in a corporate setting one’s talking about private cloud versions. And of course these can have their own rules about how contributions work, and who can access what. And the data can not only be immediately used in Wolfram Notebooks, but also in automatically generated reports, or instant APIs.

It’s been interesting to see—during the time we’ve been testing the Wolfram Data Repository—just how many applications we’ve found for it within our own company.

There’s information that used to be on webpages, but is now in our private Wolfram Data Repository, and is now immediately usable for computation. There’s information that used to be in databases, and which required serious programming to access, but is now immediately accessible through the Wolfram Language. And there are all sorts of even quite small lists and so on that used to exist only in textual form, but are now computable data in our data repository.

It’s always been my goal to have a truly “computable company”—and putting in place our private Wolfram Data Repository is an important step in achieving this.

My Very Own Data

In addition to public and corporate uses, there are also great uses of Wolfram Data Repository technology for individuals—and particularly for individual researchers. In my own case, I’ve got huge amounts of data that I’ve collected or generated over the course of my life. I happen to be pretty organized at keeping things—but it’s still usually something of an adventure to remember enough to “bring back to life” data I haven’t dealt with in a decade or more. And in practice I make much less use of older data than I should—even though in many cases it took me immense effort to collect or generate the data in the first place.

But now it’s a different story. Because all I have to do is to upload data once and for all to the Wolfram Data Repository, and then it’s easy for me to get and use the data whenever I want to. Some data (like medical or financial records) I want just for myself, so I use a private cloud version of the Wolfram Data Repository. But other data I’ve been getting uploaded into the public Wolfram Data Repository.

Here’s an example. It comes from a page in my book A New Kind of Science:

Page 833 from A New Kind of Science

The page says that by searching about 8 trillion possible systems in the computational universe I found 199 that satisfy some particular criterion. And in the book I show examples of some of these. But where’s the data?

Well, because I’m fairly organized about such things, I can go into my file system, and find the actual Wolfram Notebook from 2001 that generated the picture in the book. And that leads me to a file that contains the raw data—which then takes a very short time to turn into a data resource for the Wolfram Data Repository:

Three-Color Cellular Automaton Rules that Double Their Input

We’ve been systematically mining data from my research going back into the 1980s—even from Mathematica Version 1 notebooks from 1988 (which, yes, still work today). Sometimes the experience is a little less inspiring. Like to find a list of people referenced in the index of A New Kind of Science, together with their countries and dates, the best approach seemed to be to scrape the online book website:

ResourceData["People Mentioned in Stephen Wolfram\[CloseCurlyQuote]s \ \[OpenCurlyDoubleQuote]A New Kind of Science\[CloseCurlyDoubleQuote]"]

And to get a list of the books I used while working on A New Kind of Science required going into an ancient FileMaker database. But now all the data—nicely merged with Open Library information deduced from ISBNs—is in a clean WDF form in the Wolfram Data Repository. So I can do such things as immediately make a word cloud of the titles of the books:

WordCloud[  StringRiffle[   Normal[ResourceData["Books in Stephen Wolfram's Library"][All,      "Title"]]]]

What It Means

Many things have had to come together to make today’s launch of the Wolfram Data Repository possible. In the modern software world it’s easy to build something that takes blobs of data and puts them someplace in the cloud for people to access. But what’s vastly more difficult is to have the data actually be immediately useful—and making that possible is what’s required the whole development of our Wolfram Language and Wolfram Cloud technology stack, which are now the basis for the Wolfram Data Repository.

But now that the Wolfram Data Repository exists—and private versions of it can be set up—there are lots of new opportunities. For the research community, the most obvious is finally being able to do genuine data-backed publication, where one can routinely make underlying data from pieces of research available in a way that people can actually use. There are variants of this in education—making data easy to access and use for educational exercises and projects.

In the corporate world, it’s about making data conveniently available across an organization. And for individuals, it’s about maintaining data in such a way that it can be readily used for computation, and built on.

But in the end, I see the Wolfram Data Repository as a key enabling technology for defining how one can work with data in the future—and I’m excited that after all this time it’s finally now launched and available to everyone.

http://blog.wolfram.com/2017/04/20/launching-the-wolfram-data-repository-data-publishing-that-really-works/feed/ 1
Walking the Dog: Neural Nets, Image Identification and Geolocation http://blog.wolfram.com/2017/04/11/walking-the-dog-neural-nets-image-identification-and-geolocation/ http://blog.wolfram.com/2017/04/11/walking-the-dog-neural-nets-image-identification-and-geolocation/#comments Tue, 11 Apr 2017 17:22:19 +0000 Swede White http://blog.internal.wolfram.com/?p=35976 Walking the dog

It’s National Pet Day on April 11, the day we celebrate furry, feathered or otherwise nonhuman companions. To commemorate the date, we thought we’d use some new features in the Wolfram Language to map a dog walk using pictures taken with a smartphone along the way. After that, we’ll use some neural net functions to identify the content in the photos. One of the great things about Wolfram Language 11.1 is pre-trained neural nets, including Inception V3 trained on ImageNet Competition data and Inception V1 trained on Places365 data, among others, making it super easy for a novice programmer to implement them. These two pre-trained neural nets make it easy to: 1) identify objects in images; and 2) tell a user what sort of landscape an image represents.

The Wolfram Documentation Center also makes this especially easy.

First, we need to talk a little bit about metadata stored in digital photographs. When you snap a photo on your smartphone or digital camera, all sorts of data is saved with the image, including the location where the picture was taken. The exchangeable image file format (EXIF) is a standard developed in 1985 that organizes the types of metadata stored. For our purposes, we’re interested in geolocation so we can make a map of our dog walk.

To demonstrate how image metadata works, let’s start with a picture of my cats, Chairman Meow and Detective Biscuits, and see how the Wolfram Language can extract where the picture was taken using GeoPosition.

Walking the Dog - InOut Img1

Fantastic—we have some coordinates. Now let’s see where on Earth this is on a map using GeoGraphics. We’ve defined those coordinates as "catlocation" above. Now, using coordinates from the image of my cats dutifully keeping the bed warm, we define our map as "catmap".

Walking the Dog - InOut Img2

Excellent. Now let’s use the zoom tool to show where these coordinates are.

Walking the Dog - InOut Img3

So, yes, this picture was taken in my old neighborhood in Baton Rouge, Louisiana, where I was a grad student before starting work here at Wolfram Research (Geaux Tigers!). Very cool, and good to know that data is stored in my iPhone pictures.

Just for fun, let’s see if Wolfram’s built-in knowledge has any data on my old neighborhood, known as the Garden District, using Ctrl + = followed by input, which allows us to use the Wolfram Language’s free-form input capability.

Walking the Dog - InOut Img4

Fantastic. Let’s get a quick map of Baton Rouge.

Walking the Dog - InOut Img5

And how about a map showing the rough outline of the Garden District?

Walking the Dog - InOut Img6-2

This provides us with a rough outline of the Garden District in Baton Rouge. There is a ton of built-in socioeconomic data in the Wolfram Language we could look at, but we’ll save that for another blog post.

Since I’m not a dog owner, I asked a coworker if I could join her on a dog walk to snap some pictures to first map the walk using nothing but photos from a smartphone, then use a neural net to identify the content of the photos.

So I can just drag and drop the photos into a notebook and define them, and then their locations, from their metadata.

Walking the Dog - InOut Img7

Walking the Dog - InOut Img8

Walking the Dog - InOut Img9

OK, that’s pretty good, but let’s add some points, change up some colors and add tooltips to show the images at each stop.

Walking the Dog - InOut Img10

In the Wolfram Notebook (or if you download the CDF), when you hover the mouse over each point, it shows the image that was taken at that location. Very cool.

Next, let’s move on to a new feature in Wolfram Language 11.1, pre-trained neural nets. First, we need to define our net, and we’re going to use Inception V3 trained on ImageNet Competition data, implemented with one impressively simple line of code. Inception V3 is a dataset used for image recognition using a convolutional neural network. Sounds complicated, but we can implement it easily and figure out what objects are in the images.

Walking the Dog - InOut Img11

Now all we have to do is put in an image, and we’ll get an accurate result of what our image is.

Walking the Dog - InOut Img12

Fantastic. Let’s try another picture and see how sure the neural net is of its determination by using "TopProbabilities" as an option.

Walking the Dog - InOut Img13

So its best guess is a goose at a 0.901 probability. Pretty good. Let’s try another image.

Walking the Dog - InOut Img14

The net is less sure in this case what kind of dog this is—which is exactly the right answer: this dog, Maxie, is a mixed border collie/corgi.

Just for fun, let’s see what it thinks my cats are.

Walking the Dog - InOut Img15

Wow. That’s pretty impressive, since they are indeed tabby cats. And I guess it’s reasonable there’s a 0.0446 probability my cats look like platypuses.

Along our dog walk, we took a picture of a pond. Let’s use a different pre-trained neural net to see if it can tell us what kind of landscape it is. For this, we’ll use Inception V1 trained on Places365 data, again implemented with one line of amazingly simple code. This particular neural net identifies landscapes based on a training set of images taken at various locations.

Walking the Dog - InOut Img16

Walking the Dog - Out Img17

Very neat. Let’s try something else.

Walking the Dog - InOut Img18

OK, sure, a pasture rather than a park. But you can see that it had other things in mind. This kind of reminds me of Stephen Wolfram’s blog post on overcoming artificial stupidity. Since it was written, neural nets (and Wolfram|Alpha) have certainly come a long way.

Walking the Dog - InOut Img19

And let’s see if we can confuse it with a picture of a sculpture.

Walking the Dog - InOut Img20

Not bad.

As you can see, the pre-trained neural nets work really well. If you want to train your own net, Wolfram Language 11.1 makes it painless to do so. So next time you’re out for a walk taking pictures of random objects and want to recreate your walk from images, you can use these new features in the Wolfram Cloud or Wolfram Desktop.

Happy coding, and happy National Pet Day!

Download this post as a Computable Document Format (CDF) file. New to CDF? Get your copy for free with this one-time download.

http://blog.wolfram.com/2017/04/11/walking-the-dog-neural-nets-image-identification-and-geolocation/feed/ 0
How to Use Your Smartphone for Vibration Analysis, Part 2: The Wolfram Cloud http://blog.wolfram.com/2017/04/07/how-to-use-your-smartphone-for-vibration-analysis-part-2-the-wolfram-cloud/ http://blog.wolfram.com/2017/04/07/how-to-use-your-smartphone-for-vibration-analysis-part-2-the-wolfram-cloud/#comments Fri, 07 Apr 2017 14:02:22 +0000 Håkan Wettergren http://blog.internal.wolfram.com/?p=35872 Making tone with wine glass

Vibration measurement is an important tool for fault detection in rotating machinery. In a previous post, “How to Use Your Smartphone for Vibration Analysis, Part 1: The Wolfram Language,” I described how you can perform a vibration analysis with a smartphone and Mathematica. Here, I will show how this technique can be improved upon using the Wolfram Cloud. One advantage with this is that I don’t need to bring my laptop.

The configuration of files may vary depending on whether you use an iPhone or an Android. I used an iPhone. I also used Dropbox for storing the sound file. At the moment, the file format from the default app in iPhone, Voice Memo, saves the sound file only in M4A format, and that format can’t yet be imported with the Wolfram Language. Therefore, I used the app Awesome Voice Recorder, AVR, which can also store the file in Dropbox.

  1. First, create a Wolfram Cloud Account.
  2. Install the Wolfram Cloud app on your smartphone.
  3. If you don’t already have a Dropbox account, create one.
  4. Download an app that can save the sound file in MP3 format to your Dropbox. I use AVR.

You are now ready to create a vibration analysis tool.

With my iPhone, I recorded 10 seconds of the sound of my finger rubbing around the rim of a wine glass.

I named the file “wineglass.mp3” and stored it on Dropbox. Some simple code for the Fourier transform of that sound looks like the following:

Smartphone Vibration Analysis Part 2 - InOut Img - 1

It is now easy to deploy the same code to the Wolfram Cloud. Name the file “FFT Basic”. With modifications to obtain the sound data from a form instead of the file system, the FFT code looks like this:

Smartphone Vibration Analysis Part 2 - InOut Img - 5

Now go to the top-left menu in the mobile cloud app. Select Deployments and then Instant Web Forms, and you’ll see the executable file. Click it and then click to select the file, and the fast Fourier transform (FFT) results will be shown.

Progression of fast Fourier transform analysis on smartphone

The tool can be generalized by allowing the user to change the scale and draw a line to show known frequencies. Typical frequencies that you may want to follow in vibration analysis are gear mesh frequencies, imbalances, blade-passing frequencies and known resonances. For the wine glass, we don’t currently have a known disturbance or resonance frequency, but I included a line anyway:

Smartphone Vibration Analysis Part 2 - InOut Img - 6

Deploy the code to the Wolfram Cloud, naming the file “FFT Analysis”:

Smartphone Vibration Analysis Part 2 - InOut Img - 7

With the improved code, I can also work with the FFT plot in the app:

FFT analysis phone screenshot

This was my first experience with the Wolfram Cloud, and within an hour I had an application ready to go. The resonant frequency of the glass is 771 Hz, a frequency the human voice is capable of, so the opera trick of shattering a glass by singing is plausible. We tried using a loudspeaker playing a tone at 771 Hz, but had no success. There will be YouTube videos when we have managed this.

http://blog.wolfram.com/2017/04/07/how-to-use-your-smartphone-for-vibration-analysis-part-2-the-wolfram-cloud/feed/ 0
Communication in Industry 4.0 with Wolfram SystemModeler and OPC UA http://blog.wolfram.com/2017/03/28/communication-in-industry-4-0-with-wolfram-systemmodeler-and-opc-ua/ http://blog.wolfram.com/2017/03/28/communication-in-industry-4-0-with-wolfram-systemmodeler-and-opc-ua/#comments Tue, 28 Mar 2017 16:31:48 +0000 Markus Dahl http://blog.internal.wolfram.com/?p=35724 SystemModeler OPCUA Industry 4.0


Industry 4.0, the fourth industrial revolution of cyber-physical systems, is on the way! With it come sensors and boards that are much cheaper than they used to be. All of these components are connected through some kind of network or cloud so that they are able to talk to each other. This is where the OPC Unified Architecture (OPC UA) comes in. OPC UA is a machine-to-machine communication protocol for industrial automation. It is designed to be the successor to the older OPC Classic protocol that is bound to the Microsoft-only process exchange COM/DCOM (if you are interested in the OPCClassic library for Wolfram SystemModeler, you can find it here).

Having a standard for communication in the upcoming Industry 4.0 is important for every new connected device. With a carefully considered protocol, all of the following aspects can be included in a smart way:

  • Platform independence
  • Security
  • Extensibility
  • Information modeling

More information can be found on the OPC Foundation website. As you can see, a lot of focus is on the secure communication between all devices in the OPC UA network. Some of the companies that are extensively using OPC UA include Siemens, SAP, Honeywell and Yokogawa.

Wolfram SystemModeler and OPC UA

While the OPC Classic (also known as OPC Data Access) has had widespread adoption within many industries, including everything from paper and pulp to automotive manufacturing, it relies on traditional elements such as programmable logic controllers (PLCs) and SCADA (supervisory control and data acquisition) control systems.

With the advent of the Internet of Things and Industry 4.0, this traditional hierarchy is quickly being replaced with more flexible solutions. Computing power is becoming cheaper, and making smart sensors with built-in logic is no longer prohibitively pricy.

Since OPC UA is cross-platform compatible, it can be run on almost any device. This can, for example, be great for prototyping where you want to use the existing IT infrastructure but use inexpensive equipment for the trials. OPC UA can be configured on devices such as a Raspberry Pi, and even on your smartphone.

As in all networks and systems, some complex behavior might need to be calculated or modeled, and this is where Wolfram SystemModeler comes in. To easily be able to set up a control system that can connect to the machines using the OPC UA protocol will both provide easy integration and work as an efficient and cost-effective testing platform.

Here’s an example of creating an easy-to-understand test model in SystemModeler using the OPCUA library. As you can see in the model diagram below, a tank is set up (top left) with some input controlling the inflow to the tank. The tank model then communicates its value (current liquid level) through OPC UA to an OPC UA server. This value is then read from the server and fed as an input to a control loop that changes the liquid level of the second tank (bottom right).

SystemModeler OPCUA tank model

We have created the entire system in this model, i.e. in this test model we are not connecting to any hardware and can communicate through the OPC UA protocol and test the control system and its response on the system.

Now we are ready to connect with hardware and run this model in real time, communicating with some real-world tanks. We could just modify the model slightly by replacing the tank models with components that connect to the real tanks through an OPC server, and use the measured values of the tanks as inputs to the SystemModeler model. That model would look like this:

SystemModeler OPCUA tank model 2

Connecting to your OPC system with SystemModeler is actually this easy! In the system without the tanks, we get the measurements from the OPC server by reading the nodes “tank1” and “tank2” that are connected to sensors measuring the values of the real-world tanks. In the same way, we set the desired flow to tank 2 by writing a signal to the OPC server on node “tank2”. The node that we write this value to is then connected to a valve that adjusts accordingly.

The result of having an OPCUA Modelica Library is that we have all the power of Modelica, SystemModeler and Mathematica in our communications network. That means that all analysis tools, control systems and computational power can be integrated directly in the OPC UA industrial system network.

OPC UA with Other Libraries in SystemModeler

Imagine a scenario where you would like to connect the SystemModeler simulation to external hardware; for example, if you would like to send a control signal from an OPC UA server to a simple Arduino or Raspberry Pi, then combining OPC UA with the ModelPlug library would make a lot of sense. The ModelPlug library allows you to connect via the Firmata standard to devices such as Arduino boards.

SystemModeler OPCUA ModelPlug

Let’s use this in an example. In our server room, we have a Raspberry Pi that monitors and logs the temperature in the room. An OPC UA server was installed on the Raspberry Pi that allows any other OPC-configured client on the network to poll the server for the current temperature data. The OPCUA library is one such client. Using only two blocks, we can get the real-time temperature from the sensor into our simulation models.

With two additional blocks from the ModelPlug library, we can feed that data into an Arduino board, where it can be used to move, for example, an actuator. For now, let us construct a very simple prototype whereby the onboard light on the Arduino blinks at different intervals depending on the room temperature.

SystemModeler OPCUA Arduino map

With just a few blocks (and no lines of code), we can thus create a simple prototype of a logic control system that is ready to run without any of the pain that usually accompanies network programming. The light will always blink for 0.1 seconds, but the time when it blinks again will change depending on the temperature. If we press the play button, our Arduino will start blinking right away:

SystemModeler OPCUA Arduino temperature and timing

The higher the temperature, the shorter the blink interval, and vice versa.

This can also be great for testing out code and programs that you want to run in a production environment without risking damaging sensitive equipment. In Modelica, code and compiled executables can be imported, connected and used as a block in your model.

SystemModeler OPCUA Arduino custom mode map


Wolfram SystemModeler can be utilized very effectively when combining different Modelica libraries, such as ModelPlug and OPCUA, to either create virtual prototypes of systems or test them in the real world using cheap devices like Arduinos or Raspberry Pis. The tested code for the system can then easily be exported to another system, or used directly in a HIL (hardware-in-the-loop) simulation.

http://blog.wolfram.com/2017/03/28/communication-in-industry-4-0-with-wolfram-systemmodeler-and-opc-ua/feed/ 0
Apply Now for the 15th Annual Wolfram Summer School http://blog.wolfram.com/2017/03/21/apply-now-for-the-15th-annual-wolfram-summer-school/ http://blog.wolfram.com/2017/03/21/apply-now-for-the-15th-annual-wolfram-summer-school/#comments Tue, 21 Mar 2017 16:54:26 +0000 Lizzie Turner http://blog.internal.wolfram.com/?p=35750 Wolfram Summer School participants

This year’s Wolfram Summer School will be held at Bentley University in Waltham, Massachusetts, from June 18 to July 7, 2017.

Maybe you’re a researcher who wants to study the dynamics of galaxies with cellular automata. Perhaps you’re an innovator who wants to create a way to read time from pictures of analog clocks or build a new startup with products that use RFID (radio-frequency identification) to track objects. You might be an educator who wants to build an algebra feedback system or write a textbook that teaches designers how to disinvent the need for air conditioning. These projects show the diversity and creativity of some of our recent Summer School students. Does this sound like you? If so, we want you to join us this summer!

We offer three tracks: Science, Technology & Innovation and Educational Innovation. As a student, you will design and execute a challenging, practical project and acquire an incredible amount of knowledge along the way. At the Summer School, you will gain skills that are useful universally and network with a community of smart, creative people from all over the world. Many of our students go on to work for us in some capacity, whether that be as an employee, intern, ambassador, etc.

Mentorship at Wolfram Summer School

If you’re accepted to the Summer School, you will be mentored by top-notch staff who have made powerful and important contributions to the Wolfram Language, Mathematica, Wolfram|Alpha and more—including the inventor of the Wolfram Language, Stephen Wolfram.

The Wolfram Language has a vast depth of built-in algorithms and knowledge. Recent feature additions include a dynamic and ever-growing set of machine learning capabilities (including neural networks), as well as advancements in the areas of image processing, visualization, 3D printing, geographic information systems, natural language processing and computational linguistics and database and web frameworks, among many others.

Whatever your background, profession or future plans, the Wolfram Summer School can equip you with the computational tools you need to bring any idea to reality.

For more information, visit our website.

Apply Now

http://blog.wolfram.com/2017/03/21/apply-now-for-the-15th-annual-wolfram-summer-school/feed/ 2
The R&D Pipeline Continues: Launching Version 11.1 http://blog.wolfram.com/2017/03/16/the-rd-pipeline-continues-launching-version-11-1/ http://blog.wolfram.com/2017/03/16/the-rd-pipeline-continues-launching-version-11-1/#comments Thu, 16 Mar 2017 15:52:44 +0000 Stephen Wolfram http://blog.internal.wolfram.com/?p=35467

A Minor Release That’s Not Minor

I’m pleased to announce the release today of Version 11.1 of the Wolfram Language (and Mathematica). As of now, Version 11.1 is what’s running in the Wolfram Cloud—and desktop versions are available for immediate download for Mac, Windows and Linux.

What’s new in Version 11.1? Well, actually a remarkable amount. Here’s a summary:

Summary of new features

There’s a lot here. One might think that a .1 release, nearly 29 years after Version 1.0, wouldn’t have much new any more. But that’s not how things work with the Wolfram Language, or with our company. Instead, as we’ve built our technology stack and our procedures, rather than progressively slowing down, we’ve been continually accelerating. And now even something as notionally small as the Version 11.1 release packs an amazing amount of R&D, and new functionality.

A Visual Change

There’s one very obvious change in 11.1: the documentation looks different. We’ve spiffed up the design, and on the web we’ve made everything responsive to window width—so it looks good even when it’s in a narrow sidebar in the cloud, or on a phone.

Wolfram Language documentation

We’ve also introduced some new design elements—like the mini-view of the Details section. Most people like to see examples as soon as they get to a function page. But it’s important not to forget the Details—and the mini-view provides what amounts to a little “ad” for them.

Examples and details

Lots of New Functions

Here’s a word cloud of new functions in Version 11.1:

Word cloud of new functions

Altogether there are an impressive 132 new functions—together with another 98 that have been significantly enhanced. These functions represent the finished output of our R&D pipeline in just the few months that have elapsed since Version 11.0 was released.

When we bring out a major “integer” release—like Version 11—we’re typically introducing a bunch of complete, new frameworks. In (supposedly) minor .1 releases like Version 11.1, we’re not aiming for complete new frameworks. Instead, there’s typically new functionality that’s adding to existing frameworks—together with a few (sometimes “experimental”) hints of major new frameworks to come. Oh, and if a complete, new framework does happen to be finished in time for a .1 release, it’ll be there too.

Neural Nets

One very hot area in which Version 11.1 makes some big steps forward is neural nets. It’s been exciting over the past few years to see this area advance so quickly in the world at large, and it’s been great to see the Wolfram Language at the very leading edge of what’s being done.

Our goal is to define a very high-level interface to neural nets, that’s completely integrated into the Wolfram Language. Version 11.1 adds some new recently developed building blocks—in particular 30 new types of neural net layers (more than double what was there in 11.0), together with automated support for recurrent nets. The concept is always to let the neural net be specified symbolically in the Wolfram Language, then let the language automatically fill in the details, interface with low-level libraries, etc. It’s something that’s very convenient for ordinary feed-forward networks (tensor sizes are all knitted together automatically, etc.)—but for recurrent nets (with variable-length sequences, etc.) it’s something that’s basically essential if one’s going to avoid lots of low-level programming.

Another crucial feature of neural nets in the Wolfram Language is that it’s set up to be automatic to encode images, text or whatever in an appropriate way. In Version 11.1, NetEncoder and NetDecoder cover a lot of new cases—extending what’s integrated into the Wolfram Language.

It’s worth saying that underneath the whole integrated symbolic interface, the Wolfram Language is using a very efficient low-level library—currently MXNet—which takes care of optimizing ultimate performance for the latest CPU and GPU configurations. By the way, another feature enhanced in 11.1 is the ability to store complete neural net specifications, complete with encoders, etc. in a portable and reusable .wlnet file.

There’s a lot of power in treating neural nets as symbolic objects. In 11.1 there are now functions like NetMapOperator and NetFoldOperator that symbolically build up new neural nets. And because the neural nets are symbolic, it’s easy to manipulate them, for example breaking them apart to monitor what they’re doing inside, or systematically comparing the performance of different structures of net.

In some sense, neural net layers are like the machine code of a neural net programming system. In 11.1 there’s a convenient function—NetModel—that provides pre-built trained or untrained neural net models. As of today, there are a modest number of famous neural nets included, but we plan to add more every week—surfing the leading edge of what’s being developed in the neural net research community, as well as adding some ideas of our own.

Here’s a simple example of NetModel at work:

net = NetModel["LeNet Trained on MNIST Data"]

Now apply the network to some actual data—and see it gets the right answer:


But because the net is specified symbolically, it’s easy to “go inside” and “see what it’s thinking”. Here’s a tiny (but neat) piece of functional programming that visualizes what happens at every layer in the net—and, yes, in the end the first square lights up red to show that the output is 0:

FoldPairList[{ArrayPlot[ArrayFlatten[Partition[#1, UpTo[5]]],      ColorFunction -> "Rainbow"], #2[#1]} &,   NetExtract[net, "Input"][0], Normal[net]]

More Machine Learning

Neural nets are an important method for machine learning. But one of the core principles of the Wolfram Language is to provide highly automated functionality, independent of underlying methods. And in 11.1 there’s a bunch more of this in the area of machine learning. (As it happens, much of it uses the latest deep learning neural net methods, but for users what’s important is what it does, not how it does it.)

My personal favorite new machine learning function in 11.1 is FeatureSpacePlot. Give it any collection of objects, and it’ll try to lay them out in an appropriate “feature space”. Like here are the flags of countries in Europe:

FeatureSpacePlot[EntityValue[=countries in Europe, "FlagImage"]]

What’s particularly neat about FeatureSpacePlot is that it’ll immediately use sophisticated pre-trained feature extractors for specific classes of input—like photographs, texts, etc. And there’s also now a FeatureNearest function that’s the analog of Nearest, but operates in feature space. Oh, and all the stuff with NetModel and pre-trained net models immediately flows into these functions, so it becomes trivial, say, to experiment with “meaning spaces”:

FeatureSpacePlot[{"dog", "ant", "bear", "moose", "cucumber", "bean",    "broccoli", "cabbage"},   FeatureExtractor ->    NetModel["GloVe 50-Dimensional Word Vectors Trained on Wikipedia \ and Gigaword-5 Data"]]

Particularly with NetModel, there are all sorts of very useful few-line neural net programs that one can construct. But in 11.1 there are also some major new, more infrastructural, machine learning capabilities. Notable examples are ActiveClassification and ActivePrediction—which build classifiers and predictors by actively sampling a space, learning how to do this as efficiently as possible. There will be lots of end-user applications for ActiveClassification and ActivePrediction, but for us internally the most immediately interesting thing is that we can use these functions to optimize all sorts of meta-algorithms that are built into the Wolfram Language.


Version 11.0 began the process of making audio—like images—something completely integrated into the Wolfram Language. Version 11.1 continues that process. For example, for desktop systems, it adds AudioCapture to immediately capture audio from a microphone on your computer. (Yes, it’s nontrivial to automatically handle out-of-core storage and processing of large audio samples, etc.) Here’s an example of me saying “hello”:

Play Audio

You can immediately take this, and, say, make a cepstrogram (yes, that’s another new audio function in 11.1):


Images & Visualization

Version 11.1 has quite an assortment of new features for images and visualization. CurrentImage got faster and better. ImageEffect has lots of new effects added. There are new functions and options to support the latest in computational photography and computational microscopy. And images got even more integrated as first-class objects—that one can for example now immediately do arithmetic with:

Sqrt[2 Wolfie Image]-EdgeDetect[Wolfie Image]

Something else with images—that I’ve long wanted—is the ability to take a bitmap image, and find an approximate vector graphics representation of it:

ImageGraphics[Poke Spikey]

TextRecognize has also become significantly stronger—in particular being able to pick out structure in text, like paragraphs and columns and the like.

Oh, and in visualization, there are things like GeoBubbleChart, here showing the populations of the largest cities in the US:

GeoBubbleChart[EntityValue[United States["LargestCities"], {"Position",     "Population"}]]

There’s lots of little (but nice) stuff too. Like support for arbitrary callouts in pie charts, optimized labeling of discrete histograms and full support of scaling functions for Plot3D, etc.

More Data

There’s always new data flowing into the Wolfram Knowledgebase, and there’ve also been plenty of completely new things added since 11.0: 130,000+ new types of foods, 250,000+ atomic spectral lines, 12,000+ new mountains, 10,000+ new notable buildings, 300+ types of neurons, 650+ new waterfalls, 200+ new exoplanets (because they’ve recently been discovered), and lots else (not to mention 7,000+ new spelling words). There’s also, for example, much higher resolution geo elevation data—so now a 3D-printable Mount Everest can have much more detail:

ListPlot3D[GeoElevationData[GeoDisk[Mount Everest]], Mesh -> None]

Integrated External Services

Something new in Version 11.1 are integrated external services—that allow built-in functions that work by calling external APIs. Two examples are WebSearch and WebImageSearch. Here are thumbnail images found by searching the web for “colorful birds”:

WebImageSearch["colorful birds", "Thumbnails"]

For the heck of it, let’s see what ImageIdentify thinks they are (oh, and in 11.1. ImageIdentify is much more accurate, and you can even play with the network inside it by using NetModel):

ImageIdentify /@ %

Since WebSearch and WebImageSearch use external APIs, users need to pay for them separately. But we’ve set up what we call Service Credits to make this seamless. (Everything’s in the language, of course, so there’s for example $ServiceCreditsAvailable.)

There will be quite a few more examples of integrated services in future versions, but in 11.1, beyond web searching, there’s also TextTranslation. WordTranslation (new in 11.0) handles individual word translation for hundreds of languages; now in 11.1 TextTranslation uses external services to also translate complete pieces of text between several tens of languages:

TextTranslation["This is an integrated external service.", "French"]

More Math, More Algorithms

A significant part of our R&D organization is devoted to continuing our three-decade effort to push the frontiers of mathematical and algorithmic computation. So it should come as no surprise that Version 11.1 has all sorts of advances in these areas. There’s space-filling curves, fractal meshes, ways to equidistribute points on a sphere:

Graphics[HilbertCurve[5]] MengerMesh[3, 3] Graphics3D[Sphere[SpherePoints[200], 0.1]]

There are new kinds of spatial, robust and multivariate statistics. There are Hankel transforms, built-in modular inverses, and more. Even in differentiation, there’s something new: nth order derivatives, for symbolic n:

D[x Exp[x], {x, n}]

Here’s something else about differentiation: there are now functions RealAbs and RealSign that are versions of Abs and Sign that are defined only by the real axis, and so can freely be differentiated, without having to give any assumptions about variables.

In Version 10.1, we introduced the function AnglePath, that computes a path from successive segments with specified lengths and angles. At some level, AnglePath is like an industrial-scale version of Logo (or Scratch) “turtle geometry”. But AnglePath has turned out to be surprisingly broadly useful, so for Version 11.1, we’ve generalized it to AnglePath3D (and, yes, there are all sorts of subtleties about frames and Euler angles and so on).

A Language of Granular Dates

When we say “June 23, 1988”, what do we mean? The beginning of that day? The whole 24-hour period from midnight to midnight? Or what? In Version 11.1 we’ve introduced the notion of granularity for dates—so you can say whether a date is supposed to represent a day, a year, a second, a week starting Sunday—or for that matter just an instant in time.

It’s a nice application of the symbolic character of the Wolfram Language—and it solves all sorts of problems in dealing with dates and times. In a way, it’s a little like precision for numbers, but it’s really its own thing. Here for example is how we now represent “the current week”:


Here’s the current decade:


This is the next month from now:


This says we want to start from next month, then add 7 weeks—getting another month:

NextDate["Month"] + =7wk

And here’s the result to the granularity of a month:

CurrentDate[%, "Month"]

Talking of dates, by the way, one of the things that’s coming across the system is the use of Dated as a qualifier, for example for properties of entities of the knowledgebase (so this asks for the population of New York City in 1970):

New York City [ Dated[ "Population", 1970 ] ]

Language Tweaks

I’m very proud of how smooth the Wolfram Language is to use—and part of how that’s been achieved is that for 30 years we’ve been continually polishing it. We’re always making sure everything fits perfectly together—and we’re always adding little conveniences.

One of our principles is that if there’s a lump of computational work that people repeatedly do, then so long as there’s a good name for it (that people will readily remember, and readily recognize when they see it in a piece of code), it should be inserted as a built-in function. A very simple example in Version 11.1 is ReverseSort:

ReverseSort[{1, 2, 3, 4}]

(One might think: what’s the point of this—it’s just Reverse[Sort[...]]. But it’s very common to want to map what’s now ReverseSort over a bunch of objects, and it’s smoother to be able to say ReverseSort /@ ... rather than Reverse[Sort[#]]& /@ ... or Reverse@*Sort /@ ...).

Another little convenience: Nearest now has special ways to specify useful things to return. For example, this gives the distances from 2.7 to the 5 nearest values:

Nearest[{1, 2, 3, 4, 5, 6, 7} -> "Distance", 2.7, 5]

CellularAutomaton is a very broad function. Version 11.1 makes it easier to use for common cases by allowing rules to be specified by associations with labeled elements:

ArrayPlot[  CellularAutomaton[<|"OuterTotalisticCode" -> 110, "Dimension" -> 2,     "Neighborhood" -> 5|>, {{{1}}, 0}, {{{50}}}]]

We’re always trying to make sure that patterns we’ve established get used as broadly as possible. Like in 11.1, you can use UpTo in lots of new places, like in ImageSize specifications.

We also always trying to make sure that things are as general as possible. Like IntegerString now works not only with the standard representation of integers, but also with traditional ones used for different purposes around the world:

IntegerString[12345, "TraditionalChineseFinancial"]

And IntegerName can also now handle different types and languages of names:

IntegerName[12345, {"French", "Ordinal"}]

And there are lots more examples—each making the experience of using the Wolfram Language just a little bit smoother.

A Language of Persistence

If you make a definition list x=7, or $TimeZone=11, the definition will persist until you clear it, or until your session is over. But what if you want a definition that persists longer—say across all your sessions? Well, in Version 11.1 that’s now possible, thanks to PersistentValue.

PersistentValue lets you specify a name (like "foo"), and a "persistence location". (It also allows options like PersistenceTime and ExpirationDate.) The persistence location can just be "KernelSession"—which means that the value lasts only for a single kernel session. But it can also be "FrontEndSession", or "Local" (meaning that it should be the same whenever you use the same computer), or "Cloud" (meaning that it’s globally synchronized across the cloud).

PersistentValue is pretty general. It lets you have values in different places (like different private clouds, for example); then there’s a $PersistencePath that defines the order to look at them in, and a MergingFunction that specifies how (if at all) the values should be merged.

Systems-Level Programming

One of the goals of the Wolfram Language is to be able to interact as broadly as possible with all computational ecosystems. Version 11.1 adds support for the M4A audio format, the .ubj binary JSON format, as well as .ini files and Java .properties files. There’s also a new function, BinarySerialize, that converts any Wolfram Language expression into a new binary (“WXF”) form, optimized for speed or size:

BinarySerialize[RandomGraph[{50, 100}]]

BinaryDeserialize gets it back:


Version 11.0 introduced WolframScript—a command-line interface to the Wolfram Language, running either locally or in the cloud. With WolframScript you can create standalone Wolfram Language programs that run from the shell. There are several enhancements to WolframScript itself in 11.1, but there’s also now a new New > Script menu item that gives you a notebook interface for creating .wls (=“Wolfram Language Script”) files to be run by WolframScript:


Strengthening the Infrastructure

One of the major ways the Wolfram Language has advanced in recent times has been in its deployability. We’ve put a huge amount of work into making sure that the Wolfram Language can be robustly deployed at scale (and there are now lots of examples of successes out in the world).

We make updates to the Wolfram Cloud very frequently (and invisibly), steadily enhancing server performance and user interface capabilities. Along with Version 11.1 we’ve made some major updates. There are a few signs of this in the language.

Like there’s now an option AutoCopy that can be set for any cloud object—and that means that every time the object is accessed, one should get a fresh copy of it. This is very useful if, for example, you want to have a notebook that lots of people can separately modify. (“Explore these ideas; here’s a notebook to start from…”, etc.)

CloudDeploy[APIFunction[...]] makes it extremely easy to deploy web APIs. In Version 11.1 there are some options to automate aspects of how those APIs behave. For example, there’s AllowedCloudExtraParameters, which lets you say that APIs can have parameters like "_timeout" or "_geolocation" automated. There’s also AllowedCloudParameterExtensions (no, it’s not the longest name in the system; that honor currently goes to MultivariateHypergeometricDistribution). What AllowedCloudParameterExtensions does is to let you say not just x=value, but x__url=..., or x__json=....

Another thing about Version 11.1 is that it’s got various features added to support private instances of the Wolfram Cloud—and our major new Wolfram Enterprise Private Cloud product (with a first version released late last year). For example, in addition to $WolframID for the Wolfram Cloud, there’s also $CloudUserID that’s generalized to allow authentication on private clouds. And inside the system, there are all sorts of new capabilities associated with “multicloud authentication” and so on. (Yes, it’s a complicated area—but the symbolic character of the Wolfram Language lets one handle it rather beautifully.)

And There’s More

OK, so I’ve summarized some of what’s in 11.1. There’s a lot more I could say. New functions, and new capabilities—each of which is going to be exciting to somebody. But to me it’s actually pretty amazing that I can write this long a post about a .1 release! It’s a great testament to the strength of the R&D pipeline—and to how much can be done with the framework we’ve built in the Wolfram Language over the past 30 years.

We always work on a portfolio of projects—from small ones that get delivered very quickly, to ones that may take a decade or more to mature. Version 11.1 has the results of several multi-year projects (e.g. in machine learning, computational geometry, etc.), and a great many shorter projects. It’s exciting for us to be able to deliver the fruits of our efforts, and I look forward to hearing what people do with Version 11.1—and to seeing successive versions continue to be developed and delivered.

http://blog.wolfram.com/2017/03/16/the-rd-pipeline-continues-launching-version-11-1/feed/ 2
Visualizing Anatomy http://blog.wolfram.com/2017/03/10/visualizing-anatomy/ http://blog.wolfram.com/2017/03/10/visualizing-anatomy/#comments Fri, 10 Mar 2017 18:41:34 +0000 Jeffrey Bryant http://blog.internal.wolfram.com/?p=35450 Brain image

In Mathematica 10, we introduced support for anatomical structures in EntityValue, which included, among many other things, a “Graphics3D” property that returns a 3D model of the anatomical structure in question. We also styled the models and aligned them with the concepts in the Unified Medical Language System (UMLS).

EntityValue[{Entity["AnatomicalStructure", "LeftFemur"],    Entity["AnatomicalStructure", "LeftHand"]}, "Graphics3D"]

The output is a standard Graphics3D expression, but it contains metadata in the form of an Annotation that allows for additional exploration.

Head[Entity["AnatomicalStructure", "LeftThumb"]["Graphics3D"]]

This means each model knows what lower-level structures it’s made of.

Hip Bone and Structure Below

Computation versus Appearance

I should note that the models being used are not just eye candy. If that were the intent, we might explore low polygon count models and use textures for a more realistic appearance. But these models are not just good for looking at—you can also use them for computation. For meaningful results, you need accurate models, which may be large, so you may need to be patient when downloading and/or rendering them. Keep in mind that some entities, like the brain, have lots of internal structures. So the model may be larger than you expect, although you may not see this internal structure from the outside.

One example of using these models for computation would be calculating the eigenfrequencies of an air-filled transverse colon (let the jokes fly). Finite element mesh (FEM) calculations are common in medical research today. By retrieving the mesh from AnatomyData, we can perform computations on the model.

ev1 = AnatomyData[Entity["AnatomicalStructure", "TransverseColon"],    "MeshRegion"]

bev = BoundaryMeshRegion[MeshCoordinates[ev1], MeshCells[ev1, 2]];

nde = NDEigenvalues[{-Laplacian[u[x, y, z], {x, y, z}],      DirichletCondition[u[x, y, z] == 0, True]},     u, {x, y, z} \[Element] bev, 20];

Now we can obtain the resonant frequencies of the transverse colon.

freqs = Sqrt[    nde] QuantityMagnitude[     UnitConvert[ThermodynamicData[

You can use Sound to listen to the resonant frequencies of the transverse colon.

Play Audio
Colon Frequencies

We can find the surface area of the model by directly operating on the MeshRegion. Units are in square millimeters.


To compute the volume, we need to convert the MeshRegion into a BoundaryMeshRegion first. Units are in cubic millimeters.

Volume[BoundaryMeshRegion[MeshCoordinates[ev1], MeshCells[ev1, 2]]]

You can even compute the distance between the transverse colon and the region centroid of the large intestine. Units are in millimeters.

RegionDistance[ev1,   AnatomyData[Entity["AnatomicalStructure", "LargeIntestine"],    "RegionCentroid"]]

Lower-resolution models will give lower-quality results.

Structure and Style

To make it easy to render anatomical structures, we introduced AnatomyPlot3D.

AnatomyPlot3D[{Entity["AnatomicalStructure", "LeftFemur"]}]

AnatomyPlot3D allows directives to modify its “primitives,” similar in syntax to Graphics3D.

The output of AnatomyPlot3D doesn’t contain the original Entity objects. They get resolved at evaluation time to 3D graphics primitives, and the normal rules of the graphics language apply to them. The output of AnatomyPlot3D is a Graphics3D object.

AnatomyPlot3D[{RGBColor[0.56, 0, 0],    Entity["AnatomicalStructure", "LeftFemur"], RGBColor[   0.45, 0.58, 0.7000000000000001],    Entity["AnatomicalStructure", "RightFemur"], {RGBColor[    1, 0.81, 0.49], Entity["AnatomicalStructure", "HipBone"]},    Entity["AnatomicalStructure", "Sacrum"]}]


Because AnatomyPlot3D can be thought of as an extension to the Graphics3D language, you can mix anatomical structures with normal Graphics3D primitives.

AnatomyPlot3D[{Entity["AnatomicalStructure", "LeftFemur"],    Cuboid[{200, -44, 550}, {222, 44, 575}]}, Boxed -> True,   Axes -> True]

In AnatomyPlot3D, the Graphics3D language has been extended at multiple levels to make use of anatomical structures. Within AnatomyPlot3D, anatomical entities work just like graphics primitives do in Graphics3D. But they can also be used in place of coordinates in Graphics3D primitives like Point and Line. In that context, the entity represents the region centroid of the structure. This allows you, for example, to draw a line from one entity to another.

AnatomyPlot3D[{Entity["AnatomicalStructure", "LeftHand"],    Entity["AnatomicalStructure", "RightHand"], Thick, Red,    Line[{Entity["AnatomicalStructure", "LeftHand"],      Entity["AnatomicalStructure", "RightHand"]}]}]

This concept can be applied to annotate a 3D model using arrows and labels.

AnatomyPlot3D[{Entity["AnatomicalStructure", "SkeletonOfRightHand"],    Red, Arrow[{{-175, -130, 758},      Entity["AnatomicalStructure", "RightFifthMetacarpalBone"]}, 5],    Text["5th metacarpal", {-175, -130, 758}, {0, -1}]}]

You can refer to the subparts of structures and apply styles to them using AnatomyForm. It applies only to anatomical structures (not Graphics3D primitives) and supports a couple of different forms. The following example behaves similar to a standalone directive, except that it applies only to the anatomical structure, not the Cuboid.

AnatomyPlot3D[{AnatomyForm[EdgeForm[ RGBColor[0.42, 0.52, 1]]], Entity["AnatomicalStructure", "LeftFemur"],    Cuboid[{200, -44, 550}, {222, 44, 575}]}, Boxed -> True,   Axes -> True]

A more useful form can be used to style subparts.

AnatomyPlot3D[{AnatomyForm[<|     Entity["AnatomicalStructure", "SetOfBones"] -> RGBColor[      0.45, 0.55, 1],      Entity["AnatomicalStructure", "Muscle"] -> RGBColor[      0.93, 0.7000000000000001, 0.4]|>],    Entity["AnatomicalStructure", "LeftHand"]}]

AnatomyForm works by allowing you to associate specified directives with specified entities that may or may not exist in the structure you are visualizing. Any Directive supported by Graphics3D is supported, including Lighting, Opacity, EdgeForm, FaceForm, ClipPlanes and any combination thereof. In addition to supporting styles for specific entities, AnatomyForm also supports a default case via the use of an underscore. The following example shows the left humerus in red and everything else transparent and backlit, giving an X-ray-like appearance.

reverselights =    Join[{{"Ambient", Black}},     Table[{"Directional", Hue[.58, .5, 1],       ImageScaled[{Sin[x], Cos[x], -.5}]}, {x, 0, 2 Pi - 2 Pi/8,       2 Pi/8}]];

AnatomyPlot3D[{AnatomyForm[<|_ ->       Directive[Specularity[White, 50], Hue[.58, 0, 1, .1],        Lighting -> reverselights],      Entity["AnatomicalStructure", "LeftHumerus"] -> Red|>],    Entity["AnatomicalStructure", "LeftArm"]},   Background -> Hue[.58, 1, .3], SphericalRegion -> True]

PlotRange can make use of entities to constrain what would otherwise include all of the referenced entities. The following example includes several bones of the left lower limb, but the PlotRange is centered on the left patella and padded out from there by a fixed amount.

AnatomyPlot3D[{Entity["AnatomicalStructure", "LeftFemur"],    Entity["AnatomicalStructure", "LeftTibia"],    Entity["AnatomicalStructure", "LeftFibula"],    Entity["AnatomicalStructure", "LeftPatella"]},   PlotRange -> Entity["AnatomicalStructure", "LeftPatella"],   PlotRangePadding -> 50]

SkinStyle is a convenient way to include any enclosing skin that can be found around the specified entities.

AnatomyPlot3D[{Entity["AnatomicalStructure", "RightHand"]},   SkinStyle -> Automatic]

The default styling can be overridden.

AnatomyPlot3D[{Entity["AnatomicalStructure", "RightHand"]},   SkinStyle -> Directive[RGBColor[0.39, 0.58, 1], Opacity[.3]]]

You can use ClipPlanes to peel away layers of skin.

With[{z = 1000},   AnatomyPlot3D[{Entity["AnatomicalStructure", "LeftUpperLimb"],     ClipPlanes -> {InfinitePlane[{{0, -300, z}, {300, -300,          z + 200}, {200, 0, z}}]},     Entity["AnatomicalStructure", "SkinOfLeftUpperLimb"]}]]

Use multiple clip planes to peel away successive anatomical layers.

AnatomyPlot3D[{AnatomyForm[    Association[     Entity["AnatomicalStructure", "Muscle"] ->       Directive[RGBColor[0.43, 0.65, 1],        ClipPlanes -> {InfinitePlane[{{0, -100, 850}, {300, 0,             1050}, {0, 0, 850}}]}],      Entity["AnatomicalStructure", "Skin"] ->       Directive[RGBColor[0.43, 0.6900000000000001, 0.32],        ClipPlanes -> {InfinitePlane[{{0, -200, 1050}, {300, 0,             1250}, {0, 0, 1050}}]}],      Entity["AnatomicalStructure", "SetOfBones"] -> RGBColor[      0.9, 0.64, 0.47000000000000003`], All -> Transparent]],    Entity["AnatomicalStructure", "LeftUpperLimb"],    Entity["AnatomicalStructure", "Skin"]},   PlotRange -> {{0, 400}, {-300, 100}, {650, 1375}},   Background -> Hue[.58, 1, .3]]

Apply geometric transformations to anatomical structures to rotate them. The following example includes many bones in the skull, but applies a rotation to just the elements of the lower jaw around the temporomandibular joint.

Grid[{Table[    AnatomyPlot3D[{Entity["AnatomicalStructure", "Neurocranium"],       Entity["AnatomicalStructure", "ZygomaticBone"],       Entity["AnatomicalStructure", "SphenoidBone"],       Entity["AnatomicalStructure", "NasalBone"],       Entity["AnatomicalStructure", "Maxilla"],       Entity["AnatomicalStructure", "MaxillaryDentition"],       Rotate[{Entity["AnatomicalStructure", "Mandible"],         Entity["AnatomicalStructure", "MandibularDentition"]},        t Degree, {1, 0, 0},        Entity["AnatomicalStructure", "TemporomandibularJoint"]]},      SphericalRegion -> True,      PlotRange -> Entity["AnatomicalStructure", "Skull"],      PlotRangePadding -> 20], {t, {0, 10, 20}}]}]

A mix of styles can be useful for highlighting different tissue types in the head.

AnatomyPlot3D[{{ClipPlanes -> {InfinitePlane[{{-50, -146,          1500}, {-20, -146 - 20, 1550}, {-50, -146 - 20, 1500}}],       InfinitePlane[{{-50, -146, 1550}, {-20, -146 - 20,          1550}, {-50, -146 - 20, 1550}}]},     Entity["AnatomicalStructure", "Skull"]},    Entity["AnatomicalStructure", "Eye"],    Entity["AnatomicalStructure", "Brain"],    Directive[Specularity[White, 50], Hue[.58, 0, 1, .1],     Lighting ->      Join[{{"Ambient", Black}},       Table[{"Directional", Hue[.58, .5, 1],         ImageScaled[{Sin[x], Cos[x], -.5}]}, {x, 0, 2 Pi - 2 Pi/8,         2 Pi/8}]]], Entity["AnatomicalStructure", "Nose"],    Entity["AnatomicalStructure", "Neck"],    Entity["AnatomicalStructure", "SkinOfHead"],    Entity["AnatomicalStructure", "SkinOfNeck"],    Entity["AnatomicalStructure", "Lip"],    Entity["AnatomicalStructure", "Ear"]},   PlotRange -> Entity["AnatomicalStructure", "Head"],   PlotRangePadding -> 10, Background -> Hue[.58, 1, .3],   SphericalRegion -> True, ViewAngle -> Pi/5, ImageSize -> 600,   ViewPoint -> {-1.4, -1.29, 0.07}, ViewVertical -> {0.16, -0.08, 1.}]

A similar approach can be used in the torso for different organs.

reverselights =    Join[{{"Ambient", Black}},     Table[{"Directional", Hue[.58, .5, 1],       ImageScaled[{Sin[x], Cos[x], -.5}]}, {x, 0, 2 Pi - 2 Pi/8,       2 Pi/8}]];

reverselights2 =    Join[{{"Ambient", GrayLevel[.3]}},     Table[{"Directional", Yellow,       ImageScaled[{Sin[x], Cos[x], -.5}]}, {x, 0, 2 Pi - 2 Pi/8,       2 Pi/8}]];

AnatomyPlot3D[{Entity["AnatomicalStructure", "RibCage"],    Entity["AnatomicalStructure", "Esophagus"],    Entity["AnatomicalStructure", "Stomach"],    Entity["AnatomicalStructure", "SmallIntestine"],    Entity["AnatomicalStructure", "LargeIntestine"],    Entity["AnatomicalStructure", "Spleen"],    Entity["AnatomicalStructure", "Liver"],    Entity["AnatomicalStructure", "Lung"],    Entity["AnatomicalStructure", "Heart"],    Entity["AnatomicalStructure", "Kidney"],    Entity["AnatomicalStructure",     "UrinaryBladder"], {Directive[Specularity[White, 50],      Hue[.58, 0, 1, .1], Lighting -> reverselights],     Entity["AnatomicalStructure", "MusculatureOfTrunk"],     Entity["AnatomicalStructure", "MusculatureOfPectoralGirdle"],     Entity["AnatomicalStructure", "PectoralisMajor"]}},   Background -> Hue[.58, 1, .3], SphericalRegion -> True,   ViewAngle -> Pi/10, ImageSize -> 600,   BaseStyle -> {RenderingOptions -> {"DepthPeelingLayers" -> 20}}]

Here is an advanced example showing the use of ClipPlanes to remove muscles below a specific cutting plane.

reverselights =    Join[{{"Ambient", Black}},     Table[{"Directional", Hue[.58, .5, 1],       ImageScaled[{Sin[x], Cos[x], -.5}]}, {x, 0, 2 Pi - 2 Pi/8,       2 Pi/8}]];

With[{z = 1100},  AnatomyPlot3D[{    {ClipPlanes -> {InfinitePlane[{{0, -100, z}, {0, 0, z}, {300, 0,           z}}]}, AnatomyForm[<|       Entity["AnatomicalStructure", "Muscle"] ->         Directive[Specularity[White, 50], Hue[.58, 0, 1, .1],          Lighting -> reverselights]|>],      Entity["AnatomicalStructure", "LeftUpperLimb"]},    {ClipPlanes -> {InfinitePlane[{{0, -100, z}, {300, 0, z}, {0, 0,           z}}]}, Entity["AnatomicalStructure", "LeftUpperLimb"]}    }, Background -> Hue[.58, 1, .3], ImageSize -> {400, 700},    SphericalRegion -> True, ViewAngle -> Pi/10]]

Inner structures can be differentiated using styles, in this case within the brain.

reverselights =    Join[{{"Ambient", Black}},     Table[{"Directional", Hue[.58, .5, 1],       ImageScaled[{Sin[x], Cos[x], -.5}]}, {x, 0, 2 Pi - 2 Pi/8,       2 Pi/8}]];

reverselights2 =    Join[{{"Ambient", GrayLevel[.3]}},     Table[{"Directional", Yellow,       ImageScaled[{Sin[x], Cos[x], -.5}]}, {x, 0, 2 Pi - 2 Pi/8,       2 Pi/8}]];

With[{style =     Directive[Specularity[White, 50], Red,      Lighting -> reverselights2]},   AnatomyPlot3D[{AnatomyForm[<|      Entity["AnatomicalStructure", "Brainstem"] -> style,       Entity["AnatomicalStructure", "Hypothalamus"] -> style,       Entity["AnatomicalStructure", "Thalamus"] -> style,       Entity["AnatomicalStructure", "LateralVentricle"] -> style,       Entity["AnatomicalStructure", "ThirdVentricle"] -> style,       Entity["AnatomicalStructure", "FourthVentricle"] -> style,       Entity["AnatomicalStructure", "LateralGeniculateBody"] -> style,       Entity["AnatomicalStructure", "MedialGeniculateBody"] ->        style, _ ->        Directive[Specularity[White, 50], Hue[.58, 0, 1, .1],         Lighting -> reverselights]|>],     Entity["AnatomicalStructure", "Brain"]},    Background -> Hue[.58, 1, .3], ImageSize -> 600,    SphericalRegion -> True, ViewAngle -> Pi/6,    ViewPoint -> {-1.4, -1.29, 0.07}, ViewVertical -> {0.16, -0.08, 1.},    BaseStyle -> {RenderingOptions -> {"DepthPeelingLayers" -> 20}}]]

Here are links to some animations rendered using AnatomyPlot3D:

Mandible Opening and Closing

Rotating Head

Rotating Brain

Rotating Torso

Erasing Muscles in Arm

Scaling Transform Applied to the Bones of the Skull

As time goes on, we will continue to add additional models and tools allowing you to explore human anatomy more deeply.

To download this post as a CDF, click here. New to CDF? Get your copy for free with this one-time download.

http://blog.wolfram.com/2017/03/10/visualizing-anatomy/feed/ 2
How to Use Your Smartphone for Vibration Analysis, Part 1: The Wolfram Language http://blog.wolfram.com/2017/03/02/how-to-use-your-smartphone-for-vibration-analysis-part-1-the-wolfram-language/ http://blog.wolfram.com/2017/03/02/how-to-use-your-smartphone-for-vibration-analysis-part-1-the-wolfram-language/#comments Thu, 02 Mar 2017 17:27:27 +0000 Håkan Wettergren http://blog.internal.wolfram.com/?p=35358

Until now, it has been difficult for the average engineer to perform simple vibration analysis. The initial cost for simple equipment, including software, may be several thousand dollars—and it is not unusual for advanced equipment and software to cost ten times as much. Normally, a vibration specialist starts an investigation with a hammer impact test. An accelerometer is mounted on a structure, and a special impact hammer is used to excite the structure at several locations in the simplest and most common form of hammer impact testing. The accelerometer and hammer-force signals are recorded. Modal analysis is then used to get a preliminary understanding of the behavior of the system. The minimum equipment requirements for such a test are an accelerometer, an impact hammer, amplifiers, a signal recorder and analysis software.

I’ve figured out how to use the Wolfram Language on my smartphone to sample and analyze machine vibration and noise, and to perform surprisingly good vibration analysis. I’ll show you how, and give you some simple Wolfram Language code to get you started.

Throughout the history of the development of machines, vibration and sound measurements have been important issues. There are two reasons for this:

  1. Vibrations are a source of noise, can decrease operating performance and can also cause workplace injuries such as “vibration white fingers,” also known as hand-arm vibration syndrome (HAVS), resulting from continuous use of handheld machinery vibrating at certain key frequencies.
  2. Vibrations can indicate wear or defects of the bearings and gears, and so analysis of vibrations is a useful and commonly used tool for fault detection.

The many applications of vibration analysis have led to a huge number engineers studying this subject in universities all over the world. The research area of “machine vibrations” has its own conferences and publications. Companies specialize in developing different kinds of equipment and services. Most large machine-building industries have departments specializing in vibrations.

So here we go: recording the sound of a vibrating machine with an iPhone is simple. I used the iPhone’s built-in digital voice recorder, Voice Memo. The recording can be converted to an MP3 file just by saving it in the MP3 format in iTunes. The default Apple M4A format cannot be used directly in the Wolfram Language. If iTunes is not available, there are a lot of free converters on the internet that will change your M4A files to MP3 files.

Play Audio

I’ll use an industrial gearbox as an example. The example itself is not that important, but it does suggest possible areas where the method can be used. Some data and dimensions have been modified from the original application.

A gearbox is making a lot of noise. What is the problem?

In the figure below, a motor drives the input shaft. The shaft speed is reduced by the gearbox. The power is used by the output shaft. Typically, the motor is a diesel or electrical engine; in this example, it is a diesel engine. The number of teeth are z1 = 23, z2 = 65, z3 = 27 and z4 = 43, respectively. The largest wheels are about one meter in diameter.


We ran the engine at 1200 rpm, recording five seconds of sound with my iPhone. Converted to MP3, the sound file was named “measurement.mp3”. Then all I needed to do was import it into the Wolfram Language to plot the frequency spectrum.


The excitation frequency in Hertz of the gear contact on the input shaft is z1*rpm/60, and
(z1/z2)*z3 *rpm/60 on the output shaft. Marking the histogram for the input and output shafts’ gear mesh excitation frequencies—red and green, respectively—makes it clear that these frequencies are correlated with the spectrogram.

Excitation frequency histogram

Let’s make the spectrogram interactive: often we don’t want to use the whole sound file, so we add an option to select a start and end time within the file. Let’s also make it possible to change the rpm.

Manipulate start and stop time

The analysis toolkit is ready. The options PlotRange, MaxValue and Manipulate in the plot above are set manually. Of course, this can be developed further. But we stop here to keep it simple.

So what happened with the real application investigation? Well, the same analysis as above was performed over the whole rpm region. The maxima of the peaks at each rpm are plotted below.

Amplitude and frequency graph

The input shaft’s highest value is 747.7 rpm, and the output shaft’s is 1,800 rpm. Both become excited at about 287 Hz, the gearbox fundamental resonance frequency. Note that
747.7/60*23 = 286.6 Hz and 1800*23/65*27/60 = 286.6 Hz

We concluded that the gear mesh was not optimized for smooth running and the gearbox had a bad resonance frequency. We opened the gearbox and were able to confirm wear on the teeth, which suggested possibilities for improving the contact pattern. We improved contact by selecting an optimum helical angle, as well as tip relief and correct crowning. Tip relief is a surface modification of a tooth profile; a small amount of material is removed near the tip of the gear tooth. Crowning is a surface modification in the lengthwise direction to prevent contact at the teeth ends, where a small amount of material is removed near the end of the gear tooth.


I have used this method, utilizing my smartphone and the Wolfram Language, several times for real-world and often complex investigations and applications. Often, measurement specialists have already gotten involved before I arrive. But they may have missed the basics because they are using comprehensive measurement programs.

The method I describe here may sometimes yield a similar—or even better—understanding of the problem in just a few minutes at no cost. Well worth trying.

http://blog.wolfram.com/2017/03/02/how-to-use-your-smartphone-for-vibration-analysis-part-1-the-wolfram-language/feed/ 1