diff is a well-known program used to show the differences between two text files.  The difference can be saved in a file, and the patch utility used to reconstruct the new file from the old file.

Many revision control systems use diff, either to store the versions or, at least, to show differences between versions.  Although revision control software are mainly used by developers, if you have a lot of files you work on that you want to keep track of, some type of revision control software may be useful for you. For example, when I work on consulting projects or even on the ansys.net tips, I have lots of LaTeX, gnuplot, and ANSYS input files.  By using version control, I can go back to a previous state, if needed; moreover, I can even ‘branch’ to try different things (such as one version for print, one version for web, etc.).

I think that centralized revision control systems, such as CVS or Subversion, are overkill for non-software-development situations.  I like using Git, although Bazaar would work just as well.  A quick two-part Git Tutorial can be found here.  With git, you can keep track of changes to your documents and ANSYS macros & input files — it can also act as a backup in case you inadvertently delete a file!

As a bit of digression, the above mainly is in reference to text files, but what about binary files?  xdelta3 is a binary diff, which is useful for tracking changes to binary files.

For ANSYS users that are used to working in the GUI, keeping backup copies of the database is good practice since all work may be done interactively.  However, the binary database files can get large, and keeping many of them may eventually take up disk space (even though the .db files compress very well).  With xdelta3, one only needs to keep a copy of the original file as well as the ‘patchfile’, thus reducing disk space.

xdelta3 is usually available in most Linux distributions’ software repository, so installation should be straightforward.

In terms of using xdelta3, the syntax to create a patch file is as follows:

xdelta3 -s old.db new.db diff.xd3

This creates a patch call “diff.xd3” based on the differences between the old database “old.db” and new database “new.db”.  Now, the user only needs to keep “old.db” and “diff.xd3” (which is typically smaller), and “new.db” can be recreated from the following:

xdelta3 -d -s old.db diff.xd3 patched.db

By using sha1sum or md5sum, one can verify that “patched.db” is the same as “new.db”.

If the entire mesh changes, the patch will be large.  However, if smaller changes are made (such as adding elements or changing loading conditions), the diff file will be much smaller compared to the original database.  One can, for example, create a shell script to periodically back up .db files using xdelta3.

Binary diff programs should not be used for other ANSYS files since most ANSYS files do not have similar data; for example, if one solves a new solution, the .rst result file from one load case compared with a different load case may have little in common, so a binary diff would not be meaningful.

Also, files with internal compression probably will not work well with binary diff since a compression algorithm will make two similar patterns no longer similar.  Consequently, Workbench Mechanical .dsdb or .mechdat files will usually see no benefit using binary diff.

Most users have a lot of disk space, so using binary diff is not frequently needed, and most of this discussion on binary diff is just “interesting” rather than “practical” (although even whether it is “interesting” depends on your point of view).  However, xdelta3 provides a means of keeping multiple revisions of ANSYS .db files — as noted earlier, a shell script could be run at intervals in the working directory to create ‘patches’ of file.db based on an original file.db to backup that day’s work (rather than relying on the user to manually backup files), or if one needs to archive data on optical media (CDs, DVDs), use of patches saves space.  (Of course, compression should be used as well after the binary diff.)

Another program, bsdiff, also provides similar functionality, but I found this to take too much CPU time.  For executables, which are typically smaller in size, bsdiff seems to provide more space savings than xdelta3 (consequently, bsdiff is used more for creating ‘patches’ for software binaries), but for large ANSYS .db files, one may find that bsdiff takes too long to run.