Yesm it should be possible to do this.

How exactly depends on what properties of the adjacent elements you need - if it is only properties that are available at the beinning of an increment, you can use the call to uexternaldb at this point to write these data into a field that is in the common block.

Otherwise, you will probably also have to use getvar-routines to access the data.

I am not sure whether you can access element connectivity with CALL GETNODETOELEMCONN (according to the manual, it is only available from umeshmotion) - otherwise, you could read this off the inp-file on the very first call to uexeternaldb.

Thank you for your response Dr. Baeker. Let me explain it more.

Considering damage mechanics in a three-phase model (one solid and two fluid phases), typical solid elements at each increment may sustain damage due to loading. Depending on the sort of fluid elements, surrounding the solid ones, the damaged elements are going to be filled with fluid. So I assume a field variable should be defined to identify the type of each element at the start of each increment.

Now, the adjacent elements have to be recognized, for example by their coordinates or the elements' label. Then, the type of each adjacent element has to be identified, for example by means of above-mentioned field variable. Finally, this information is going to be utilized within UMAT to calculate the response of elements at the end of each increment.

I think the method you pointed out regarding UEXTERNALDB will be OK if this way yields information for all elements in the model at the beginning of each increment before UMAT calculations, which is done element by element. But, I have no idea about "getvar-routines" unless you meant GETVRM utility routine provided by ABAQUS. As regards GETNODETOELEMCONN, I would share your idea as it is restricted to UMESHMOTION subroutine. Anyway the idea of identifying adjacent elements through inp-file was really inspiring.

Actually, I am new in using UEXTERNALDB and I am not sure about how it works and how it could be used. However, let me explain my inference and I would be more than glad to have your comments. Assuming UEXTERNALDB provides elements information related to the whole model at the beginning of each increment (not just for one element), the read information will be written in common block. Then, UMAT or USDFLD will use written data (containing adjacent elements information) to predict surrounded element behavior.

Again, I would like to ask others as well to leave their ideas and comments with this regard .

Dear Ramin,

yes, I think you are right and this is how it may work. I did indeed mean GETVRM and related routines to access the information. You may also gather element-specific information in USDFLD and store it in a user-defined material field.

I'm sorry to bump this thread, but the problem here is very relevant compared to what I am currently attempting.

I intend to prevent the usage of common blocks (other than for reading purposes) to perform non-local bookkeeping, etc. for a UMAT. In order to do so I want to combine a USDFLD (or UVARM) with a UEXTERNALDB routine. What is still unclear to me is how for example the UVARM or USDFLD derived information can be imported in UEXTERNALDB. As far as I have been able to find UEXTERNALDB only reads from and writes to external files. Is this really the case or can fields also be imported directly for example? If not, how can this data exchange be performed most efficiently. Is this where URDFIL comes in for example?

I would like to learn your opinions on this, I'm under the impression some of the question followers have some ideas ready. 

Hi, I have a similar problem, I need to get the stress value from a truss to modify the material of another, how have you solved?