Akanksha Parmar, Imagine two processors trying to access and update the same value in a COMMON block at the same time. In a non-ideal scenario, one processor might read the old value, update it, but before writing the update back, the other processor reads the same old value and also tries to update it. This can lead to inconsistencies and unexpected results because the final value in the COMMON block depends on the unpredictable timing of these accesses. That is the whole problem and in troubleshooting you need to check your subroutine where the dependency on the calculations is.

Engr. Tufail, Thank you. I understand. Do you think this problem can be solved using mutex?

Akanksha Parmar, Yes, that'll prevent conflict.

Thank you Engr. Tufail I have not used mutex earlier and I can use some help.

I have included the following in my code:

#include

include 'vaba_param.inc'

Then I initialize variables.

do 100 k = 1, nblock

call MutexLock(1)

...

...(coding)

...

call MutexUnlock(1)

return

end

However, I am getting the following error when I run my job:

grain_growth_data_mutex.for(90): error #5082: Syntax error, found POUND_BASE '' when expecting one of: ; TYPE INTEGER REAL COMPLEX BYTE CHARACTER CLASS DOUBLE ...

#include

----------^

grain_growth_data_mutex.for(90): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: ...

#include

-----------------------------------------------^

Could you please suggest some ways to fix the errors?

Thank you again for all your time and effort!

Thanks,

Akanksha

Akanksha Parmar The error is related to the compiler, it is not recognizing the syntex. Rest body of code is correct. Use .F file as well as remove the < > and replace it with ' ' to check the status of your file.

Thank you for your suggestion Engr. Tufail . I changed my subroutine from .for to .f and replaced the with single quotes. However, I still get similar error:

grain_growth_data_mutex.f(90): error #5082: Syntax error, found POUND_BASE '' when expecting one of: ; TYPE INTEGER REAL COMPLEX BYTE CHARACTER CLASS DOUBLE ...

#include 'SMAAspUserSubroutines.hdr'

----------^

Followed by a lot of errors in the actual subroutine, which didn't exist without mutex and SMAAsp file.

Based on some posts, I have also tried adding the following before and after #include statement:

!DEC$ NOFREEFORM

!DEC$ FREEFORM

But that didn't help either.

I don't know how to read these errors. Could you help? Thank you!

Akanksha Parmar The error now you are getting is because of non recoginisable syntax parameter in line 90 of your code. Check that. Beside " !DEC$ NOFREEFORM !DEC$ FREEFORM" won't help you in this regard.

Hello Engr. Tufail Line 90 is actually the include line. I am attaching a screenshot here.

Akanksha Parmar, Yes, that means the error occurs because of the inclusion of this portion. I am sorry, i don't have access to Fortran otherwise i'd have troubleshooted that properly.

Hello Engr. Tufail What would be the correct way to use mutex then?

Thank you!

Akanksha Parmar Here is how it works: https://abaqus-docs.mit.edu/2017/English/SIMACAESUBRefMap/simasub-c-getthreadid.htm

Hello Akanksha,

The problem comes from using common blocks while running a process on multiple cores. The VUHARD subroutine is accessed simultaneously from every core and potentially modifies the values inside the common block. If that is the case, then you are dealing with a thread-safety problem, every thread (core) is accessing the memory address of the common block in any arbitrary order, and potentially overwriting data.

The bad news is that your current implementation may only work on a single core.

The good news is that there are ways to solve it. Depending on what you do in the subroutines, you can take advantage of Mutex (https://help.3ds.com/2023/English/DSSIMULIA_Established/SIMACAESUBRefMap/simasub-c-getthreadid.htm?contextscope=all) or allocatable arrays that are thread-safe (https://help.3ds.com/2023/English/DSSIMULIA_Established/SIMACAESUBRefMap/simasub-c-localarrays.htm?contextscope=all).

I hope you find it useful!

Best regards,

Miguel

It is because of how Abaqus accesses to user subroutine. One easy way you can try is to add "parallel = solver" when you use command line to submit your job. E.g. abaqus job ="job name" input="job file name" interactive cpus = " the numebr of cpus" parallel =solver.

Hope it would help.

Chi

I think the command suggested by Chi Wu is 'standard_parallel', instead of parallel. That should work as well, the subroutine won't be called simultaneously this way.