nasa / nasa/CompDam_DGD

Parallelization and initializing multiple materials

Open
#22 2 comments 0 reactions 0 assignees View on GitHub

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.