background: Abaqus provides a number of Fortran subroutine "templates" (in fixed-format/F77 style) that allow users to get specific info or influence certain aspects of the solution during an analysis, aka user-subroutines. Abaqus controls when the user-subroutines are called, what info is passed in/out, etc. Users cannot change any of that, and have no access to the main program or its proprietary source code. However, within a user-subroutine, the user is free to write any valid code they feel is necessary.
In this question, the OP wants to store information from each call to the dflux user-subroutine so that it is available to other subroutines or to other calls to the dflux subroutine. Note: this capability is not provided by dflux, so the OP needs a work-around.
possible work-arounds: Luckily, the dflux user-subroutine provides the element number, the integration point number, and the spatial coords for the current call. This info can probably be used to store (and access) any data you need. The data storage/transfer method might be accomplished through a COMMON block, a Fortran module, or even a text file or some other external "database".
> I recommend the module-based approach. However, see this answer for a good explanation of how to use both COMMON blocks and modules.
(EDIT) For completeness, a very simple example with a module and an abaqus subroutine could be structured something like:
module data_mod
! Any routine may access this module with the statement: "USE data_mod".
! Any variable within the module is then shared by those routines.
implicit none
! You can use an allocatable array, but for this example I will assume
! there are 1000 or fewer points, and up to 10 values for each.
real, dimension(1000,10) :: point_data
end module data_mod
subroutine dflux(....all the args...)
! Note: you must "USE" modules before any other statements in the routine.
use data_mod
! Now you may carry on with the rest of your code.
! Be sure to have the required "INCLUDE 'ABA_PARAM.INC" statement,
! which defines how abaqus implements "IMPLICIT REAL" for your machine,
! and all of the boilerplate variable declarations included with the
! DFLUX subroutine template.
include 'aba_param.inc'
(...etc...)
! For simplicity, I am assuming you have a unique ID for each point, and
! each ID is numerically equal to one of the row indices in 'point_data'.
! When ready to read/write data in the 'point_data' array:
! Read data:
neighbor_vals(:) = point_data(NEIGHBOR_ID, 2:)
old_data_at_current_point(:) = point_data(ID, 2:)
(...etc...)
! Write data:
point_data(ID,2:4) = coords(:)
point_data(ID,5) = result1
point_data(ID,6) = result2
end subroutine dflux
> You will need to choose a type of data container and some clever organizational concept - perhaps using the element number, integration point number, or the (x,y,z) coordinates to uniquely identify the data you want to store. For instance, a simple 2-dimensional (MxN) array might be sufficient: each row represents the Mth integration point, the first column contains the unique point identifier(s), and the remaining columns contain any values you want to store from each point. Note: Determining which points are "neighbors" is another topic you will need a clever solution for. Once you've done this, perhaps neighboring points can be stored in the array as well, for faster access.
> You are safe reading data from other integration points stored in the data container, but do not write/change the values stored in the data container (whether it is within a COMMON block or a module) unless it is for the current integration point where dflux is currently being called.
side notes:
- New users often think they are stuck writing FORTRAN 77 in their Abaqus user-subroutines. They aren't.
- The easiest way to use modules along with abaqus user-subroutines is to place them at the top of your file. Abaqus will then compile and link them automatically when you run the analysis.
