Become one with your modeling tool

I was planning on announcing GeoStudio 2012 on this blog, but now it has been out for two months, and I had to have a reader prod me to comment on it.  *Sigh*

It’s been a busy couple of years working on the latest version of GeoStudio, but now that it’s out I hope I can get back to regular blogging about new features.

Regular Updates

Perhaps the most important change in GeoStudio 2012 is not in the software itself, but in how we deliver it.  Our goal is to provide frequent updates throughout the year, with new features as well as bug fixes coming out every couple of months.

Traditionally, software gets released once and then you don’t hear from the company again for a couple of years while they work on the next version, and that is how we have worked in the past as well.  The problem with that approach is that early in that silent period we’ve worked on some great new features but we can’t let anyone use them because we have to save them up for the next version.  We frequently have intense discussions about “is it a bug or is it a feature”, because we would allow bug fixes to be released mid-stream but features had to wait.

Now we can avoid those discussions and really focus every month on the top priorities, whether they are bugs or new features, and customers on the annual maintenance plan get to take advantage of the changes as soon as they are implemented.

Productivity

Our focus with GeoStudio 2012 was on getting out of the way.  You spend too much time closing windows, changing some mode, then re-opening the same window, instead of being able to focus on the engineering model itself.  We’re trying to find all those pain points and smooth them out.

One way we’re doing that is by adding docking windows. In SLOPE/W, for example, the Slip Surfaces window is always there, and you can pick a different slip surface at any time, whatever else you’re doing.  Similarly the finite element products show all the Result Times and let you pick a new one without having to close your graph window or whatever else you were looking at.

We noticed that solving took a lot of clicks:

1. Tools – Solve Analyses
2. “Yes” I want to save changes.
3. (optionally) select the analyses to solve
4. “Start”
5. (optionally) close the Solver window when it’s done
6. Close the “Solve Analyses” dialog
7. Window – CONTOUR

Phew!  Then of course if you don’t like the results you click to go back to DEFINE, make a couple of changes, and go through those 7 steps again.

In GeoStudio 2012, the Solve Manager is a docking window that you can leave around all the time, so solving looks like this:

1. (optionally) select the analyses to solve
2. click “Start”

GeoStudio will automatically switch to Results View (previously known as CONTOUR) as soon as it starts solving, and will show results as soon as they’re available (even before it finishes solving).

Save As 2007

You can create a file in GeoStudio 2012 and save it as a GeoStudio 2007 file.  This is something you’ve been asking for for years, and I’m very happy to announce it’s finally possible.  This will allow you to upgrade only some of your licenses, or to work with partners who have not yet upgraded.

Of course there are caveats–if you use new engineering features in 2012 and save to 2007, of course GeoStudio 2007 doesn’t know anything about the new features so they will be lost.  But if you stick with the 2007 feature set, you should be able to exchange files without too much trouble.

We have always made sure new GeoStudio versions could open files created by older versions (in fact you can a PC-SLOPE file if you want, from the days before Windows).  But now we can finally go the other way around.

Engineering

I don’t normally talk about strictly engineering features, because that is outside my area of expertise, but I’ll mention a couple of the features our engineers are most proud of.

In the finite element products, our engineers have changed the convergence schemes, and as a result many analyses can be solved more quickly; many analyses that used to run into convergence problems will solve more reliably; and (they say) the new convergence scheme is easier to understand and troubleshoot.  This is all way over my head but it sounds great!

Solver speed has been improved across the board, and several analyses can be solved simultaneously to better take advantage of today’s multiple cores.

Lots More

I’ve touched on a few of the big changes today, but of course there are many more.  I’ll try to get back to weekly blogs focusing on specific features and giving more of my insider tips.

If any of you are using GeoStudio 2012 already, leave a comment and tell us your experience so far.

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

John asked some specific questions about the file format, which makes it much easier to add a Part 3 to my series about the GeoStudio xml file format.

Nate, the reason I asked for the XSD is that I would like to write an XML-file from scratch, perform a batch calculation with it (Bishop, using CU-values) and then read the stability result (Safety factor). Could you tell me: A) which blocks are realy needed in the XML to do this (I guess I do not have to write the View block for instance)? B) where I can find the result in the XML? I see there are other (result) files but was wondering whether the result would be in the xml as well.

I’ll give you some suggestions here, but you’ll need to do some tests to see if I’m 100% accurate and if it matches your needs. I suggest you use GeoStudio to create an analysis similar to what you need, then do a File – Save As, change the “Save as type” to “GeoStudio File (*.xml)”, and save it. That will give you an xml file you can look through for starters, without having to go through the hassle of a zip file all the time. Now find the portions of the file you think may not be necessary, and delete them (or comment them out) one at a time, save it, try opening it in GeoStudio and see if there are any errors reported. For example, you’ll need the Analyses section, but within that section you can likely get rid of the InputFiles. Here are the major sections I’m guessing you should be able to get rid of completely without the SLOPE/W solver caring:

• BCs – slope doesn’t use boundary conditions
• Contour – only used if you’re using GeoStudio to look at the results (and I think it will open fine without this section, just using defaults)
• Functions – unless you’re using functions of course, in which case you can still get rid of the Boundary subsection and keep only Material.
• MeshItems – no mesh in slope
• SketchItems – that’s only for markup
• View – that’s just view preferences

Which leaves you with only:

• Analyses – the analysis settings
• Contexts – the “associations” I’ve described in the past, such as which material is associated with which region in which analysis.
• Coordinates – this one may even be optional, since we really only use units for labelling things.
• FileInfo – define at least the FileVersion–this helps GeoStudio load the xml data correctly.
• Functions if you use any
• GeometryItems – defines your regions, lines and points
• Materials – defines the materials
• SlopeItems – defines slope-specific objects such as slip surface definition. 

Results

The results are not stored in the xml file.  There are lots of results generated, and xml is too verbose and would inflate the file size unnecessarily.  Instead results of finite element analyses are all stored in csv files–with a bonus that they are easy to open in a spreadsheet application, as well as being easy to parse in code.  Results of slope analyses are not in csv format; they are in text files which are supposed to be easy to figure out.  Here’s what the GeoStudio 2007 User’s Guide says about them:

All of the SLOPE/W output files have column descriptions that explain what each data set represents.  If you have specific questions or it is not clear, please contact GEO-SLOPE via e-mail at support [at] geo-slope [dot] com. The following files are created by SLOPE/W: Factor of safety:  *.FAC Slice forces:  *.FRC01 and OPTFRC Probability and sensitivity:  *.PRO01 and OPTPRO Permanent deformation (Newmark with QUAKE/W):  *.NEW

Open a solved gsz file in your favourite zip application (I use 7-Zip), and you’ll see a folder with the same name as your analysis.  Each solved analysis stores its results in its own folder. Inside that folder you’ll see another xml file–that’s a snapshot of the main xml file as it was when the analysis was solved. You’ll also see additional numbered folders, these are the time steps.  Each time step’s results gets its own folder. All these result folders will contain csv files (for finite element analyses) or .fac/.frc files (for slope/w).  The .fac file summarizes the factors of safety.  The .frc01 file contains the computed forces for all slices of the critical slip surface.  If you’ve opted to store results for more than one critical slip surface, then the next most critical will be stored in .frc02, and so on. The User’s Guide suggests you email support if you need help understanding the format of the result files.  If you need a quick answer, that’s still your best bet, but I’m also happy to answer questions through blog comments as I have time.

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.