zip

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.

Mike recently emailed me from Australia trying to understand why a long analysis name would cause a “Path too long” error when running Verify.

Background - Path Length

Windows imposes a maximum number of characters allowed for any path, including the drive letter, the directories, and the file name. In XP I believe the limit is 260 characters.

In this example (and in Mike’s case) his file name was within the 260 character limit that Windows imposes on paths.

The problem is a bit hidden, and has to do with how GeoStudio handles .gsz files.

A Gsz is a Zip File

I’ve mentioned before that a .gsz file is really just a Zip file that can be opened with WinZip or any other Zip reader.

When GeoStudio opens a .gsz file, it unzips any internal files it needs into your TEMP directory. In Windows 2000, Windows 98, and older versions, the TEMP directory is normally C:\TEMP. But in XP (and Vista) each user on a computer gets their own TEMP directory for privacy reasons, so the path is something like:

C:\Documents and Settings\YourUsername\Local Settings\Temp\

That’s a pretty long path to start out with. Maybe you can see where this is headed.

After that TEMP path, GeoStudio adds a unique folder name that is derived from the name of the .gsz, so now we’re up to something like:

C:\Documents and Settings\YourUsername\Local Settings\Temp\gs_Your Gsz File Name_89284fa64a8df8a7cf04a40a75c2b96c\

That’s the root folder the .gsz gets unzipped into. Nasty. But that’s not all, oh no, that is not all!

Inside that folder you get another folder named after each analysis. Now we’re at:

C:\Documents and Settings\YourUsername\Local Settings\Temp\gs_Your Gsz File Name_89284fa64a8df8a7cf04a40a75c2b96c\Your Descriptive Analysis Name\

Inside that analysis folder you get one folder for each time step:

C:\Documents and Settings\YourUsername\Local Settings\Temp\gs_Your Gsz File Name_89284fa64a8df8a7cf04a40a75c2b96c\Your Descriptive Analysis Name\001\

And for the coup de grâce, in SLOPE/W we then fnish the path off with the name of the analysis again (in the flow products we use shorter names like “nodes.csv”):

C:\Documents and Settings\YourUsername\Local Settings\Temp\gs_Your Gsz File Name_89284fa64a8df8a7cf04a40a75c2b96c\Your Descriptive Analysis Name\001\Your Descriptive Analysis Name.frc01

You can see that even if you keep your filename and analysis names below the 260 character limit, you may still end up going over the limit inadvertantly. With SLOPE/W especially, keeping your analysis names shorter makes a big difference since they are used twice.

Verify

The good news is that in the latest versions, Verify catches the problem. In earlier versions it wasn’t so friendly. I don’t remember if it would crash, give strange results, or if the solver would just give an unhelpful error message.

If you get the “Path too long” error in Verify, just shorten your analysis name and/or the name of your .gsz file.

One of our users asked me recently for advice on picking the best hardware configuration to run GeoStudio.  His office was buying new computers for their engineers and since they used GeoStudio heavily they wanted the best possible configuration within their budget.

The System Requirements on our web site are obviously pretty basic.  And they don’t tell you where you should spend that extra budget to really get the most bang for your buck.  Here are my suggestions.

Processor

GeoStudio 2007 is multi-threaded, meaning it will take full advantage of multiple CPUs or cores.  Don’t worry too much about processor speed: get at least a dual-core CPU and your solves will be nearly twice as fast.  The improvement will be more obvious the larger your typical mesh sizes.  Here’s a graph to give you a rough idea of the speed improvements additional processors will give you.

GeoStudio 2004, on the other hand (version 6), is not multithreaded, so additional CPUs will not typically help unless you’re running two analyses at the same time.

Additionally, GeoStudio is optimized for 32-bit CPUs.  You may as well get 64-bit CPUs and a 64-bit OS because that’s the way the industry is headed, but that won’t translate into better performance with GeoStudio today.

Memory

After investing in a dual-core CPU, the next biggest bang for your buck will be memory.  With the price of memory these days you shouldn’t use less than 2 GB.  Go with 4 GB if you can.  Large meshes use lots of memory, and if you don’t have enough RAM then your operating system will be swapping data back and forth between disk and RAM, which will really slow things down.

Graphics

Any self-respecting graphics card with basic 2D acceleration will be able to handle GeoStudio’s graphics just fine.  Until we get into 3D, you don’t need to worry about your graphics card.  (Note that Seep3D is a whole other question–it definitely needs a good OpenGL-accelerated card.  But that’s beyond the scope of this blog.)

Disk

CPU and RAM are obvious.  But these days process and memory are getting so fast that they are less likely to be the bottleneck any more.  The next place to spend money is on a fast hard drive.

If you’ve used version 4 or earlier of our products, you’ll remember the hundreds of files a typical solve would spit out.  It’s only gotten worse!  With version 5 we introduced the .*z files (.slz for slope, .sez for seep, etc), which just hid the mess of files in one zip file.  Version 6 changed that to a .gsz, which combined all the files for several different analyses into one zip file.  And version 7 is worse yet since you can have as many analyses as you want all in the same .gsz file.  While the solver is running it is reading and writing and zipping and unzipping at each iteration and time step.  Contour isn’t quite as bad as Solve since it’s not writing results, but it still has to read a lot of data.

Scott Guthrie recommends programmers buy faster hard drives, but his advice is appropriate for GeoStudio users too.

Laptops:  Most laptops come by default with a 5400rpm drive, which is pretty slow.  Consider spending another $55-$100 to upgrade to 7200rpm instead.

Desktops:  Desktops normally ship with 7200rpm drives.  I recommend getting 10,000rpm or higher instead.  It could also be beneficial to go with a RAID 0 striped configuration, which splits data across multiple drives, lowering the seek time.

Conclusion

CPU and RAM are still the most important ingredients in a fast computer, but it’s the number of CPUs that counts, not the speed.  And if you still have money left over in your budget, get yourself the fastest hard drive you can afford.  You won’t regret it.

Back with version 5 of our products (we called it “GEO-SLOPE Office” back then, but it’s the same thing as what you know as GeoStudio now), each product had its own file format.  (I think v5 was when we first introduced file zipping though, so all the results for an analysis were at least in one big file instead of creating a zillion little files to keep track of.)  In version 6 (aka GeoStudio 2004) were able to combine all products into one, letting you have a (single) SEEP/W analysis in the same file as a SLOPE/W analysis.  Version 7 (GeoStudio 2007) takes the final step, letting you have as many analyses as you want all in one file.

But with that added power comes added complexity.

GeoStudio 2007 tries to help you keep track of changes to all those analyses by indicating when an analysis may need to be re-solved.  It does that by showing a status of “solution out of date” next to some analyses in Tools - Solve Analyses.

But what really does “Solution out of date” mean?

It means that some values have changed which could affect the solution.  That’s rather vague.  Phrased another way, if you solve that analysis again, your results may be different from last time. 

More specifically, an analysis will NOT be out of date if all you’ve changed is sketch text or sketch lines, or if you changed a function or material or boundary condition that isn’t actually used by that analysis.  In the example above, I changed a material property that is obviously only used by the SLOPE/W analyses.

To find out exactly what changed, you can select an out of date analysis and click the Show Changes button.

In this case I can see that I changed Phi from 34 to 33.

So what about the ‘*’ in the title bar?  What’s that?

Some people seem to confuse “solution out of date” with the “*” that shows up in the title bar from time to time.  The “*” is much dummer than the “solution out of date”.  All it means is that something (pretty much anything) has changed, so you may want to save your file.  When the “*” is there and you try to close GeoStudio, you’ll get prompted to save.  That’s all it means.  There’s no global “Show Changes” button, but if you click the arrow next to the Undo button in the toolbar you can see the last few changes that have been made.

I hope that demystifies how GeoStudio keeps track of changes.  Computers are not fast enough (yet!) for all your solutions to be automatically kept up to date, but with the clues you can gather from the Show Changes button you have enough information to know whether you need to solve an analysis again or leave it be.

I love being able to keep all my analyses together in one file with GeoStudio 2007, it far easier to organise things, and under the hood it lets us do smarter things in the code, like sharing the geometry and mesh between all analyses, or placing analyses on a timeline to view results across multiple analyses.

But it makes for really large files.  And sharing those files becomes a pain.  Try emailing your 30 MB .gsz file to a colleague or to our tech support and you may be rudely reminded your IT department limits your emails to 10 MB.  (In fact I hear Greg right now in the office next to mine on the phone telling somebody to “save your file without solution and email it to me…”)

Fortunately it’s easy to get rid of some of that excess baggage using what we call the “Save As Without Solution” option.  Choose File – Save As, then change the “Save as type” option to “GeoStudio Compressed Excluding Solution (*.gsz)”.

That option strips out all results from the file, saving only the definition, bringing you down to something typically under a couple hundred KB.

The down side of course is that your colleague will need a license in order to re-solve all the analyses before being able to look at any results.  If you’re sending it to a supervisor who just wants to use the free Viewer license to look at results, this won’t work so well.  Or maybe your colleague has a license but it takes two days to re-solve the analysis.

In that case an option would be to remove results for some analyses but leave others.  Say you have ten analyses in the file because you were trying out a few options, but your supervisor only needs to look at two of them.  You could Save As without Solution, then re-solve just those two analyses.

The .gsz file is really just a zip file.  So for fine-tuned (if a bit risky) accuracy you can open the .gsz file in WinZip or your favourite zip utility and delete the entire folder that has the name of the analysis whose results you want to nuke.  For example, here I would delete everything in the folders named “1 – Initial pwp\” and “1 – Initial pwp01\” to delete results for an analysis named “1 – Initial pwp”.

This gives you a bit more fine-grained control over what results to keep and what to discard.

Other ideas include saving results for fewer time steps.  (Do you really need to save results for every second of a 365–day analysis?)  Or use fewer sample slip circles.  Of course you end up with less data, so that will have to be a judgment call you make as an engineer.

There will still be times when you simply cannot delete any results, they must be included, and the file is still large.  Unfortunately there’s not much that can be done at that point except to find an alternate way of sending the file.  If we’re doing tech support and need a large file from you we give you temporary access to an ftp account that will let you upload your file with no size restrictions.  Within your organization you can likely use a shared folder over the network.  There are also some file sharing web sites out there but I have not used enough to recommend one.  Have you?  Leave a comment and let me know how you send large files.

Hopefully this gives you at least a bit more control over your file sizes.  Disk is cheap, but transmitting all those bits can still be an issue!