Parallelization and initializing multiple materials
Nobody has claimed this yet.
- Dominant language
- Fortran
- Stars
- 160
- Forks
- 68
- PR merge metrics
- No merged PRs in 30d
Description
Hello,
I have been using CompDam for a couple of years and recently tested multiple user materials in the same Abaqus input file with parallel execution.
Context: I am simulating a laminate with material properties varying through the thickness, e.g. changing fiber volume fraction as a function of ply position in the layup. Implementing this in the Abaqus input is straightforward because each ply can be assigned a different user material through element sets.
However, when running CompDam_DGD.for with multiple Abaqus/Explicit packager threads / CPUs, multiple threads can enter the material-cache allocation block at the same time:
If (Allocated(user%materials)) Then
mats = Size(user%materials)
readMaterial: Do I = 1,mats
If (user%materials(I)%name == trim(cmname)) Then
m = user%materials(I)
Exit readMaterial
End If
If (I == mats) Then
Call log%info("Saving user material #"//trim(str(I+1))//": "//trim(cmname))
! Store all existing material data in temp array
Allocate (user_temp%materials(mats))
user_temp%materials(:) = user%materials(:)
! Increase size of user%materials by 1
Deallocate (user%materials)
Allocate (user%materials(mats+1))
! Return old material data to resized user%materials
user%materials(1:mats) = user_temp%materials(1:mats)
Deallocate (user_temp%materials)
! Add new material data to resized user%materials
user%materials(mats+1) = loadMatProps(cmname, nprops, props)
m = user%materials(mats+1) ! Abbreviate
! Calculate alpha0
If (m%matrixDam) Then
m%alpha0_deg = NINT(m%alpha0*45.d0/ATAN(one))
m%alpha0 = alpha0_DGD(m)
End If
! Run consistency checks
If (totalTime == zero) Then
Call consistencyChecks(m, issueWarnings=.TRUE.)
Else
Call consistencyChecks(m, issueWarnings=.FALSE.)
End If
! Make sure updated values in m are retained
user%materials(mats+1) = m
End If
End Do readMaterial
Else
Call log%info("Saving initial user material: "//trim(cmname))
Allocate (user%materials(1))
! Load the first material
user%materials(1) = loadMatProps(cmname, nprops, props)
m = user%materials(1) ! Abbreviate
! Calculate alpha0
If (m%matrixDam) Then
m%alpha0_deg = NINT(m%alpha0*45.d0/ATAN(one))
m%alpha0 = alpha0_DGD(m)
End If
! Run consistency checks
If (totalTime == zero) Then
Call consistencyChecks(m, issueWarnings=.TRUE.)
Else
Call consistencyChecks(m, issueWarnings=.FALSE.)
End If
! Make sure updated values in m are retained
user%materials(1) = m
!!! -- Not a thread safe material allocation loop
End If
This appears not to be thread-safe. The shared saved material cache, user%materials, can be resized, deallocated, and reallocated while another thread is reading or modifying it. In practice, this produces repeated/duplicated material-loading messages such as the same material being saved multiple times, followed by inconsistent property errors such as missing E1, G12, or XT, even though the corresponding .props files are valid and load correctly in serial.
The issue disappears when running serially. As a local test, wrapping the material-cache lookup/allocation/loading section in an OpenMP critical section and compiling with /Qopenmp appears to resolve the race:
!$OMP CRITICAL(CompDamMaterialCache)
! lookup user%materials
! resize/cache material if not found
! call loadMatProps(...)
! run consistency checks
! save updated material back to user%materials
!$OMP END CRITICAL(CompDamMaterialCache)
for this, /Qopenmp needs to be added to the fortran compiler options in the environment file.
This is probably just a quick fix though. It might be better to modify the script to force serial material allocation or to do some sort of thread pooling across the number of prop files in the directory to allow for some form of parallel allocation without the problems stated above.
Hope that helps, works for me at the moment :D.
Best,
Marcus
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in CompDam_DGD.for at the material-cache allocation and lookup block shown in the issue, then inspect the Fortran compiler options in the environment file, including /Qopenmp. Reproduce the serial and parallel cases and verify that concurrent material loading no longer duplicates messages or produces missing-property errors. Done means multiple materials load consistently under parallel Abaqus/Explicit execution without breaking serial behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- fortran
- Domain
- performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100