I’m utilizing a big crystal plasticity materials simulation code written in Fortran and only in the near past developed an odd problem. I’ll attempt to clarify the related elements of the code right here, and if there are any recommendations to seek out out why this bug is occurring, it could be a lot appreciated!

Discovery of the issue:

Whereas operating in launch mode, the code triggers an entry violation error that doesn’t seem in debug mode.

Utilizing print statements, I found the integer variable array, named iParentGrainRex, that saved indices used to reference different array parts is corrupted. As an alternative of storing values of 1 to 200, it has some massive values like -1020391029, suggesting reminiscence leak or corruption points. Once more, this doesn’t occur in debug mode, so I can’t discover any problem with the algorithms of the code.

The pc is new, so {hardware} causes are unlikely.

The array iParentGrainRex is statically declared to be of dimension NGR, which is a continuing outlined in a continuing module. The precise dimension of iParentGrainRex getting used is far smaller. For an preliminary knowledge dimension of 200, iParentGrainRex is initialized on line 3 within the following code snippet:

          ...
          do ng = 1,ngrain
            iParentGrainRex(ng) = ng
            iChildGrainRex(1,ng) = ng
            nChildGrainRex(ng) = 1
          enddo
          print *, 'iParentGrainRex 100: ',iParentGrainRex(100)
      endif
      print *, 'iParentGrainRex 100 1: ',iParentGrainRex(100)
      !learn state variables (different calls to umat)
      !earlier process
      if (TIME(2).ne.0.0.or.i_prev_proc.eq.2) then
          name read_statv(s,fileprev,NSTATV,STATEV,ns)
          name get(s)
      endif
      print *, 'iParentGrainRex 100 2: ',iParentGrainRex(100)
      ...

The codes earlier than and after are omitted. As we are able to see, every ng aspect in iParentGrainRex is initialized to integer ng. The endif on line 8 makes positive this initialization solely happens as soon as. The worth of iParentGrainRex is saved in a state variable array, s, that’s handed between the code and one other code that controls a larger-scale simulation, the state variable is used to save lots of the fabric situations at each step of the simulation. The dealing with of the state variable is completed in subroutines like read_statv, get(s), write_statv, and set(s).

Right here is the place it will get unusual:

After I added the print assertion on line 16 solely, we are able to see the reminiscence problem:

The identical occurs if I solely add the print statements on traces 7 and 16. However once I add the print assertion on line 9, every thing is instantly regular:

This doesn’t point out the code block between traces 9 and 16 that comprises read_statv is problematic. As a result of on time 0, all 3 print statements returned regular values when line 9 was added. However it has points when line 9 isn’t there.

Moreover, this impacts different parts. Right here I added print statements for aspect 99 on traces 7 and 16, and we see the problem persists:

However once I added the print assertion for aspect 100, it additionally solved the problem for different parts within the array:

That is to this point solely discovered to be fastened with the print assertion. After I reassign the worth of the aspect with iParentGrainRex(100) = 100, it fixes it for the aspect, however not different parts:

It’s value noting this doesn’t occur to the opposite two variables which can be additionally declared in the identical module and initialized in the identical spot as iParentGrainRex: