I recently found two Zip disks in my office. They were the next big thing for about 15 minutes in the late 1990s and early 2000s.
I then got my hands on an external Zip drive and was able to offload the disks’ contents. One disk has lecture notes and assignments from a few graduate courses I took. Those materials will come in handy the next time I teach finite elements or computational mechanics.
The other disk has the OpenSees source code from 2001 and a version 1.2 Windows executable.
Putting items on a Zip disk was one of many common pre-cloud behaviors that are now considered odd. So, examining the disks is like studying the artifacts of an ancient culture. What follows is my archaeological report.
I double-clicked the version 1.2 Windows executable, not expecting it to run, just hoping that it wouldn’t corrupt my computer. Nothing terrible happened, only a system error regarding Tcl 8.3.
Today, OpenSees is on version 3.1.0 and it requires Tcl 8.6, which this Python3 module is going to swallow whole.
The source code snapshot is far more intriguing. When OpenSees moved to GitHub, the SVN logs were brought along, but only back to 2011. I’m not sure why the logs stopped there, but it means the 2001 source code pre-dates written history.
I could go through all the folders and catalog the differences between then and now, but that would be incredibly boring. Instead, I’ll focus on the two directories, SRC/element and SRC/material/uniaxial, where most contributions from the OpenSees community have landed over the years.
Here are the subdirectories in the SRC/element directory of 2001.
There was, more or less, one element class in each subdirectory.
Here are the subdirectories in the SRC/element directory today.
Many of these subdirectories, e.g., UWelements and PFEMelement, contain multiple element classes. Plus, some of the subdirectories from 2001 have new additions, e.g., the thermal formulations in dispBeamColumn.
Turning to the SRC/material/uniaxial directory, here are its subdirectories and cpp files from 2001.
Woah! There’s only Steel01 and Concrete01, and wrappers around FORTRAN code for Drain and Fedeas material models. Did the users of OpenSees version 1.2 belong to a primitive hunter-gatherer society? How did they complete Ph.D.s and earn tenure with such basic tools?
Compare that dearth of models to what’s in the SRC/material/uniaxial directory today.
Note that I had to change my terminal window from 80×24 to 155×28 to make everything fit for the screenshot. There are now several concrete and steel and IMK models, and lots of other stuff–a grocery store on every corner. But you still need to hunt and gather to earn tenure.
If GitHub suddenly disappeared, somehow taking everyone’s local repos away with it, we could reconstruct OpenSees from this Zip disk. If that did happen, what should we do differently? Is there a Lougle opportunity here? Let me know your thoughts in the comments section.
Portwood Digital 
How interesting! Was there MVLEM element in 2001?!!!
I think you have traveled back to 2001.
I personally expect that GitHub shut down” tomorrow”. I have made a backup plan.
There are similar companies, I think Bitbucket is one of them.I, however; prefer GitHub, since it’s simpler, and easier for me to understand as well as I’m pretty dumb.
About OpenSees, Many researchers use the last source and can be called upon to receive the latest version, if GitHub shut down.
LikeLike
Hello MSB,
MVLEM didn’t show up until 2015! I don’t think GitHub will shut down any time soon either, but what should be done differently if OpenSees had to start over?
LikeLike
Compared to other software like Abaqus, I think OpenSees is like the plane’s flight recorder. I think it wasn’t supposed to be like that. Training is needed on how to use the source as well as the elements and materials given their limitations.
LikeLike
You mean the “black box”? Ha ha! Documentation, verification, and validation are things we would do much better if starting over with OpenSees 🙂
LikeLike
Before OpenSees has been moved to github, I had done my own migration of the svn repository to github and I have the history down to September 2000. Here are the first entries from my git log:
…
7. Adding feap.lib to repository – Sat Sep 16 03:10:51 2000
6. Adding Win32 FORTRAN libraries to repository
5. Adding Windows libs to repository
4. Adding VC++ project files to repository
3. Adding VC++ project files to repository
2. fmk – Initial Import into CVS
1. Standard project directories initialized by cvs2svn. : Fri Sep 15 08:23:30 2000
Therefore either github trimmed the history or somebody requested the limitation on the available history during the svn to git convertion.
LikeLike
Hello Seweryn,
Thanks for going through the SVN logs! It appears we were focused on VC++ and the FORTRAN and FEAP libraries before updating any C++ code. I also have the SVN logs going back to 2000, but I’m not so sure the diffs are stored. If so, the “original” 2000 version of OpenSees could be re-constructed.
LikeLike
Hello Michael,
The converted svn2git repository enable us to re-construct whatever state of OpenSees we would wish. All the svn logs (with svn commit numbers) and the diffs are there. I have just tested and went back to Sep 15, 2000 – the second commit “fmk – Initial Import into CVS” 🙂 Using ‘git checkout git_hash’ and back ‘git checkout master’ works very fast (half a second on my laptop) because git effectively stores every state of the project, not just diffs as in svn. I can share this converted OpenSees git repository if needed.
LikeLike
It would be interesting to benchmark the current OpenSees against a version compiled from early source code. Does it run faster now, or slower??
LikeLike