Become one with your modeling tool

Here’s an interesting bug a customer reported today (if you’re the type who finds bugs interesting).

The customer found that when he plugged an external monitor into his laptop, he could no longer use the mouse wheel to zoom in and out in GeoStudio.  Same problem with the 2004 and 2007 versions.

My first reaction was that it was a problem with his laptop’s drivers (because if it’s a bug in our software, it’s probably my fault, and that could never be!  But some quick experimenting showed me it happens even on my computer, though I’d never noticed it before.

It turns out the problem only shows itself when you run GeoStudio on a second monitor that is to the left or above your primary monitor.  If you run it on your primary, or on a second monitor positioned to the right or below, zooming works fine.

Sound weird?  Well there’s some logic to it, and an easy workaround.  You see, Windows assigns coordinates to every monitor, relative to the primary.  The primary monitor always has the coordinate 0, 0 in its top left corner.  That means a monitor to the left will have a negative coordinate such as -1024, 0.  A monitor above the primary would have a negative y coordinate like 0, -800.  Apparently there’s a bug somewhere such that if either of the screen’s coordinates is negative, zooming in GeoStudio using the mouse doesn’t work.

I haven’t taken the time yet to dig into the code to see why that is, but the obvious workaround is to position your secondary monitor to the right of your primary.

There you go–a glimpse into the life of a GeoStudio developer’s day, and a workaround to an annoying bug at the same time.

Those of you on twitter may be interested to know that GEO-SLOPE is now tweeting. Follow us on twitter @geoslope or visit twitter.com/geoslope.

Since most of you my readers are GeoStudio users, you’re likely already aware that the software itself lets you know when a new version is available to download.

Now your IT department can be alerted too, without having to actually run GeoStudio. Who knows, they may actually proactively keep your software updated!

Just go to the geo-slope.com home page and click on one of the RSS feed icons under the “Software Updates” label, then subscribe using your favourite RSS client.

XML File Format Series
1. Exploring the XML File Format
2. Exploring the XML File Format - Part 2
3. Exploring the XML File Format - Part 3 - SLOPE/W

Last month I gave an overview of the major blocks within GeoStudio’s xml file format.  Today I’m going to dig a little deeper into one of those xml blocks.

I’ll start with the <GeometryItems> section because it’s something all GeoStudio users should be familiar with.  It will demonstrate some guidelines common to the other blocks as well.

<GeometryItems>

The “geometry” of your problem, as we refer to it, is composed of points, lines and regions.  But regions and lines are just collections of points, so let’s look at the <Points> block first.

<Points>

The <Points> block is a collection of <Point>s.  You’ll see this type of xml construct often in our files, as much of the data you define involves collections of objects.

Len=”8″

The first thing to notice is the Len=”8″ in the opening tag, which indicates that there are eight points in this collection.  This is not required in standard xml, but it is required for GeoStudio.  Specifying the size of the list up front allows GeoStudio to read the file more quickly because it knows how much memory to allocate.

ID=”1″

The next thing to point out is that each point has a unique ID.  This ID is what is used elsewhere in the xml to refer to a particular point.  I can’t remember off-hand if the IDs must start at one and be sequential, but since this file format was intended to be written and read by GeoStudio, not by humans, you’d be advised to stick to that rule.

X=”0″ Y=”40″

Now we finally get to the actual definition of the point, which is just an x,y coordinate, in the units you specified in Set Units & Scale (or in the <Coordinates> block of the xml file).

<Mesh>

You should generally leave this alone.  It indicates the version of the mesh generator that was used to generate a mesh.  If you’re generating your own file, just leave this out completely.

<Plane>

I have no clue what this is about!  Anybody else know?!

<Lines>

You can see that Lines are similar to Points in some ways.  There’s that Len=”9″.  There’s the ID.  But why does the <Lines> collection contain <Lines> instead of containing <Line>s?  And why are each of the nine <Lines> a block instead of a single element like the <Point>?  Wouldn’t it be more succinct to say <Line ID=”1″ PointID1=”1″ PointID2=”2″/>?

I wish I knew the answer.  Probably an oversight.  But the problem with publishing a file format is that once it’s out there, it’s very tough to change without breaking old files, so now that’s the way it is.

Both formats are valid xml, but GeoStudio will expect one or the other so always use another gsz file as an example when hand-crafting your own.

And that’s the inside scoop you only get on GrokkingGeoStudio.com!

<PointID1>, <PointID2>

Now we see why it was important for each <Point> to have an ID field.  A line is made up of two points, identified by the point IDs.

Note that the order of the two points does matter in some situations.  While it’s not legal to have two lines with the same points just in a different order, still the order is used when you get into things like interface lines, which allow you to assign a material to one side or the other of the line.

<Regions>

Regions, like lines, are a collection of point IDs.  Only in this case there can be any number of points, so they are presented as a comma-separated list.

A region is always a closed polygon, so it’s implied that the last point in the list connects back to the first point.

The order of the point IDs is obviously important for regions, as they define the region edges.

Interestingly, a region is not a collection of Line IDs.  That used to be the case, but as we’ve begun adding circular regions and lines that don’t belong to regions, that has become too restrictive.  As you work with the user interface you can think of a region as being composed of lines, but in the data file that is not the case.

Summary

So we’ve seen several common themes:  the Len tag, the ID tag, collections of objects.  We’ve seen how some things are done differently:  using a single xml element vs using a block.  And we’ve seen how the ID is used to point to one object from another.

If I write a Part 3 I’ll add to those concepts by digging into a more complicated part of the file.  I’m open to suggestions!

XML File Format Series
1. Exploring the XML File Format
2. Exploring the XML File Format - Part 2
3. Exploring the XML File Format - Part 3 - SLOPE/W

Let’s take a deeper look into the .gsz file format.  You’ll remember I’ve mentioned a few times that a .gsz file is just a zip file that contains a bunch of other files.  One of those inner files is what we call the definition file.  The definition file has a .xml extension and generally has the same name as the .gsz.

(If you’ve solved your analyses you’ll see several .xml files.  The definition file is the one in the root directory.)

I’m assuming you are already somewhat familiar with xml in general.  If that’s not a fair assumption, you may want to do some additional reading:

• XML Tutorial for the very beginner.
• XML definition on wikipedia.

The XML

I’m going to look at the definition file for SLOPE Tutorial.gsz, since it’s included with every installation of GeoStudio. You can also download it here.

There’s a lot of detail in the definition file. Today I’ll just look at the bigger blocks. I may delve into more specific areas in later posts, depending on what feedback I get from you.

Use Notepad or Internet Explorer to open SLOPE Tutorial.xml if you want to follow along.  The first line is:

<?xml version=”1.0″ encoding=”utf-8″ standalone=”yes”?>

That’s the first line of any xml file, and simply defines it as being xml.

<GSIData Version=”7.15″>

The next line is the opening tag that defines this as a GeoStudio file, the “GSIData” block.  (”GSI” stands for “GEO-SLOPE International”.)  This line also identifies the version of GeoStudio that saved the file.

Now comes the good stuff.  A while back I described how a GeoStudio file has “global” objects such as regions and materials which are available to every analysis, and how when you assign a material to a region you’ve just formed a link or “association” between those two objects.  Well this next level in the xml file describes all those “global” objects.

<Analyses Len=”2″>…</Analyses>

The Analyses block describes each analysis.  (From KeyIn - Analyses.)

The Len=”2″ part just indicates how many analyses there are.  It’s not strictly necessary in normal xml, but it helps GeoStudio load the file more quickly because it knows in advance how many analyses are in that block.

<BCs Len=”8″>…</BCs>

The BCs block describes each boundary condition.  (From KeyIn - Boundary Conditions.)  Note that not every boundary condition in the list is necessarily used by your analyses–in fact there are a handful of default boundary conditions created in every file because they’re so common.\

<Contexts Len=”2″>…</Contexts>

This is where the associations are recorded.  There’s a context for each analysis to record which regions and materials are connected, which lines and boundary conditions, and so on.

<Contour>…</Contour>

The Contour block describes how results are visualized.

<Coordinates>…</Coordinates>

Defines the engineering coordinates, page extents and so on.  (From Set - Units & Scale and Set - Page.)

<FileInfo … />

Contains information about the file.  (From KeyIn - Analyses, then click on the root item in the tree.)

<Functions>…</Functions>

The Functions block holds all the functions you’ve defined.  (From the various KeyIn - Functions.)  They’re split into several categories such as <Boundary>, which in turn contains categories such as <StressStrain>.

<GeometryItems>…</GeometryItems>

This is your geometry definition.  It contains coordinates for all the points, lines and regions.

<Materials Len=”2″>…</Materials>

All materials you’ve defined.  (KeyIn - Materials.)

<MeshItems>…</MeshItems>

The mesh that was generated from your regions.  Note that when you open a file, the mesh may be regenerated, so don’t edit this section, your changes may not be used.  If you want to adjust your mesh, you must do it in the GeometryItems section by applying mesh constraints to regions, lines or points.

<SketchItems>…</SketchItems>

Contains sketch lines, circles, text, images and so on.  All the “markup” that doesn’t actually affect results.  (From the Sketch menu.)

<SlopeItems Len=”2″>…</SlopeItems>

Each product (SLOPE/W, SEEP/W, etc.) can have its own section with data that’s specific to that product.  For example, SLOPE/W uses this section to describe slip surfaces, piezometric lines, and so on.  Like the <Contexts> section, there is one <SlopeItem> section per SLOPE/W analysis.

<View>…</View>

Your view preferences, most recent zoom and scroll position, and so on.

</GSIData>

And finally we’re done with the outer GSIData block.

That’s the GeoStudio xml format at a very high level.  I’ll dig deeper into specific sections over the next few weeks.  Let me know if there is anything in particular you’d like covered.

Giang, if you’ve discovered some gems of wisdom as you’ve been working through this yourself, feel free to share!

I don’t normally talk about new features before they’re released, but today is an exception.  Currently in beta (and a free download), version 7.15 of GeoStudio 2007 will now allow Windows to search within .gsz files.

Update 25 September:  version 7.15 has now been released.  The release can be downloaded from here.

(This feature will only be officially supported on Vista and Windows 7, though there are reports it sort of works on XP and Windows 2000 as well.)

For example, I’ve got some GeoStudio files in my Documents folder on Windows 7.  Rather than finding the name of the file I want, I can search right from the Start button for some words inside the file.

Here I’ve searched for “toe drain”, and (in amongst a bunch of html files) I’ve found two GeoStudio files that have “toe drain” somewhere inside them.

Open one of them up, and we can see “toe drain” appeared in several places:  the file’s comments as well as each analysis’ description.

In fact, Windows Search will search the author, file comments, analysis names and descriptions, and most other objects you can name (such as materials, boundary conditions, and so on).

If you are using Vista or Windows 7 already, I encourage you to download the beta and try this feature out.  Leave a comment here or email me with any suggestions or problems you run into.

A GeoStudio user commented on an earlier post (”solving in batch mode”) asking how to generate thousands of similar analyses that differ only by some input parameters.

Interesting question, and I’d like to hear more about what it is he’s trying to accomplish.  But in the meantime here are some thoughts.

Sensitivity

In SLOPE/W, take a look at the Sensitivity analysis (KeyIn Analyses - FOS Distribution - Sensitivity).

That will let you specify a range of values for certain properties (such as C, Phi and Unit Weight in the material properties), and will re-run the analysis many times.

In Contour you can then do things such as graphing how the FOS is affected by varying Phi. (In the menu that’s Draw - Sensitivity.)

Probability

Similarly you can do a Probabilistic analysis in SLOPE/W, where Solve takes care of varying the parameters in a random way using a distribution function you define. It then gives you a probability of failure instead of a factor of safety.

You can find an example of sensitivity and probabilistic stability analyses on the geo-slope.com web site.

Add-Ins

The other products (Seep, Sigma, etc) do not have sensitivity analyses built in.  (It’s a feature we’re considering adding, so email or leave a comment to cast your vote if you would use it.)

I could imagine doing something similar using an Add-In and a batch file. The batch file could make many copies of the file, giving each a unique name (”dam-1.gsz”, “dam-2.gsz”, etc), then solving each. An Add-In function would be used to specify the property you want to vary. The Add-In would look at the file name (the “1″ or “2″ part of it) to return a different value for each run.

Not a particularly elegant solution, but it would do the trick. Of course you’d end up with hundreds of files and no simple way to compare results or graph results across the varying parameter as you can do in Slope.

Add-Ins are beyond the scope of what I can go into today, but I have been wanting to delve into them on the blog at some point. Let me know if that would interest you.

XML

An even more adventurous route would be to edit the xml inside a gsz file.  (I mentioned in passing in a few other posts that a .gsz is just a zip file that contains a bunch of other files–one of the xml files it contains is what actually defines all the data in your model.)  The advantage would be you could avoid having thousands of files and instead have just a few files each containing a number of analyses.  That lets you share data (so that moving a point in one file wouldn’t have to be duplicated to all the others), and you may also be able to take advantage of the fact that GeoStudio can graph across analyses.

But editing the xml is not something we officially support, so you’re on your own if you choose that route.

I’m curious what it is you’re doing with your thousands of files. Can you share some more detail? Do the tips I mentioned help? We’re working full-force on the next version of GeoStudio at the moment, so this is a great time to hear about features that would be important to you.

Last year while discussing hardware recommendations for getting the most out of GeoStudio 2007, I mentioned that the solvers are multi-threaded, “meaning [they] will take full advantage of multiple CPUs or cores.”

But a QUAKE/W user showed me that’s not true in all cases.  He had a QUAKE/W analysis that was only using one of his four cores, and asked me why that was, or what he could do to change it.

That was news to me, and at first I thought it was a bug, but after some digging through the code and discussing with other engineers in the group, I learned a valuable lesson.

It turns out QUAKE/W will take full advantage of multiple CPUs when using the Parallel Direct Solver option but only for Initial Static and Nonlinear Dynamic analyses.  The Equivalent Linear analysis types are not currently formulated in a way that lends itself to parallelization, and thus even if you choose the “Parallel Direct Equation Solver” option, they will only use a single core while solving.

We did have some other suggestions, however, for how this customer could greatly speed up solving his analysis.  Some of these may help you as well.

Shorten the Earthquake Record

This customer had over 12,000 data points in his earthquake record.  That means over 12,000 finite-element analyses for each iteration. 

Much of this is unnecessary.  The first thing to do is to lop off the ends.  Normally in an earthquake record the beginning and end can be lopped off, as the vibrations are small enough as to not affect the final solution. 

In this case we suggested getting rid of the first five seconds and the last 25 or so, which I’ve highlighted here.

We’ve just cut down the number of data points to 5000, less than half.  That cuts the solve time less than half too.

Resample the Earthquake Record

This record’s data points are 4/1000 sec apart.  That kind of precision is likely not necessary for a geotechnical analysis. 

Use Excel to remove every other data point, then re-scale the record so it still has the same peak accelerations, and you’ve reduced the number of equations by half again, still likely without affecting your results.

Understand the Equivalent Linear Method

Remember what the EL method is all about.  You are looking for only one number for each element and taht is the maximum dynamic shear stress.  This usually occurs at one of the peaks.  All analyses after the peak has been established are irrelevant to the analysis.

Simplify the Mesh

Especially in the early stages of an analysis, when you’re trying to answer some initial questions, use a simple mesh.  For example:

• if you know all the important activity will be in one area, get rid of mesh detail a long way from that area;
• stick to just a few materials and a couple of regions;
• try a 1D column to start with.

Besides making for shorter solve times, a simpler geometry and simpler mesh also makes it easier to understand and interpret the answers you’re getting.  You can add complexity later and watch how (or if) it affects what you’ve understood so far.

Happy meshing!

Happy New Year to all my readers!

A coworker recently pointed me to Dave’s landslide blog, by Dave Petley, the Wilson Professor at Durham University in England. Today’s article is an interesting look at a slide at a Tennesses power plant a few weeks ago (which amazingly claimed no lives).