R.M. Brannon, A.F. Fossum, and O.E. Strack
Kayenta continuous yield surface. (a) three-dimensional view in principal stress space, (b) the meridional “side” view (thick line), and (c) the octahedral view
The physical foundations and domain of applicability of the Kayenta constitutive model are presented along with descriptions of the source code and user instructions. Kayenta, which is an outgrowth of the Sandia GeoModel, includes features and fitting functions appropriate to a broad class of materials including rocks, rock-like engineered materials (such as concretes and ceramics),and metals. Fundamentally, Kayenta is a computational framework for generalized plasticity models. As such, it includes a yield surface, but the term“yield” is generalized to include any form of inelastic material response including microcrack growth and pore collapse. Kayenta supports optional anisotropic elasticity associated with ubiquitous joint sets. Kayenta support optional deformation-induced anisotropy through kinematic hardening (inwhich the initially isotropic yield surface is permitted to translate in deviatoric stress space to model Bauschinger effects). The governing equations are otherwise isotropic. Because Kayenta is a unification and generalization of simple models, it can be run using as few as 2 parameters (for linear elasticity) to as many as 40 material and control parameters in the exceptionally rare case when all features are used. For high-strain-rate applications, Kayenta support rate dependence through an overstress model. Isotropic damage is model through loss of stiffness and strength.
FORTRAN source code for a program that computes all elastic constants when you give it any two independent ones. Continue reading
FORTRAN source code for a program that does simple pre-processing tasks, many of which are especially useful for converting fortran source code (e.g., changing all in-line comments to ANSI standard F77 style).
You may download the rest of the document here.
One of these days, you might encounter FORTRAN source code (very common in legacy material models even in modern C++ codes). You might have to “tweak” the FORTRAN even if you aren’t an expert. This program illustrates how to read and write numbers and strings in FORTRAN, which should familiarize you with the syntax. See next entry for further assistance in deciphering Fortran.
You may download the program here.
I have found the ‘xargs’ command line utility to be very useful sometimes. Often you can avoid writing a special shell script to perform a task by using xargs to perform a task on a list of files. Its use can best be described through an example. I have recenlty be migrating files from one svn repository to another. I began by copying all of the files over using rsync. This copied all of the .svn files from the old repository, which I didn’t want. This left me with at least 30 directories, each with a .svn directory that needed to be removed. What to do? Use xargs. Here is the command:
command-prompt> find -name .svn | xargs rm -rf
This uses the find command to generate a list of all files and directories names ‘.svn’ (case sensistive). This list is then piped to the xargs command, which runs ‘rm -rf’ on each file in the list. That’s it! Note that as this command is written it will seach the current directory and all subdirectories for files with name ‘.svn’. If you want to have ‘find’ search a directory other than the current directory you can add the path of that directory after the file name to search for. See the man page for find for more info.
I remember learning how to use a debugger and Utah State University as an undergraduate. We learned to program in Fortran 90, and used a Microsoft debugger. It seemed cool, but honestly with the types of programs I was writing at the time, using print statement seemed to be effective enough and less of a hassle. Recently I have been working with the Uintah MPM code, which is MUCH larger and more complex than any code I’ve ever written. After several months of wading through the code I finally came across a problem that “cout” just could not help me solve. The code was suddenly crashing with an allocation error and giving no useful backtrace information. A colleague suggested that I use gdb to find out where the problem was occurring. It turned out to be very, very helpful and surprisingly easy to use. I’ve recently become a convert to Emacs, and found that the gdb interface in Emacs is especially nice. So here is goes: