Welcome to Adams/Solver Subroutines - Kxcad.net

Welcome to Adams/Solver Subroutines
be made about user-written subroutines. Consequently, by default, all user-written subroutines are
executed serially. By default, no user-supplied subroutine will take advantage of the parallel capabilities
of Adams/Solver (C++).
Because complex models often use user-written subroutines extensively, it can greatly improve
performance to execute these in parallel, as well. If this is to be done, you must ensure that the userwritten
subroutine and its dependants are threadsafe. If so, the user-written subroutine can indicate this
with a call to ADAMS_DECLARE_THREADSAFE. This call should occur during subroutine
initialization (iflag = true). Adams/Solver (C++) then permits threads to make simultaneous calls to that
user-written subroutine. For more information, see the PREFERENCES statement.
Writing Threadsafe Code
While a complete guide to writing parallel code is left to other texts, a few general points are covered
here.
Code can be made thread-safe by eliminating any possibility for data (program variables) to be shared
between different threads. For example, if all variables in a user-written subroutine were either passed in
as arguments or are dynamically allocated local variables, then that user-written subroutine would be
threadsafe.
Coding in such a manner, however, is often not practical. There may be a need for a user-written
subroutine to access constant tabular data or other parameters, which is most efficiently implemented as
global data and shared by multiple threads. To allow for this, during subroutine initialization, all userwritten
subroutines are run serially. In addition, calls to REQSUBs are always performed serially.
General Guidelines
1. The only data that can be modified at any time is:
Dynamically allocated local variables.
Static or global variable that are uniquely indexed so there is no possibility that two threads will
modify them simultaneously. For example, a user-written subroutine with a static array of data
could safely modify the array element that is uniquely mapped to the ID of the current modeling
element being evaluated. Because each thread is evaluating a different modeling element, the
threads will not access the same array element at the same time.
2. All data that will be shared by multiple threads must be allocated and set during subroutine
initialization. At other times, this data may be read, but must not be written to.
3. No special coding practices need to be followed inside a REQSUB.
FORTRAN-Specific Guidelines
1. Some FORTRAN compilers (such as Digital/Compaq Visual FORTRAN) statically allocate
local variables by default. This is avoided by using a compiler option (/automatic) that causes all
local variables to be allocated on the stack (unless the SAVE statement is used).
9