xcompact3d / x3d2

https://xcompact3d.github.io/x3d2
BSD 3-Clause "New" or "Revised" License
3 stars 4 forks source link

Fix null pointer to mesh #102

Closed JamieJQuinn closed 2 months ago

JamieJQuinn commented 2 months ago

After compiling with nvfortran, the code would fail during runtime with the following error:

Parallel run with            1 ranks
0: Null pointer for mesh%geo (/home/jjquinn/projects/xcompact/x3d2/src/xcompact.f90: 71)

--------------------------------------------------------------------------
Primary job  terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:

  Process name: [[8151,1],0]
  Exit code:    127
--------------------------------------------------------------------------

The compilation and run steps on Sylvain's Kolmogorov machine are:

cmake -DCMAKE_BUILD_TYPE=Debug -B build -DCMAKE_Fortran_COMPILER=mpif90
cmake --build build -j18
mpirun -n 1 build/src/xcompact

This PR removes the allocatable attribute on mesh and changes both mesh and its contained geo and par members to type instead of class. I'm don't know this feature of Fortran well enough to explain why this works but it fixes the problem...

Additional nonsense: The unit test that uses the same pattern or allocatable + class passes fine. No idea why.

Nanoseb commented 2 months ago

Ah yes, it makes some sense. If you have a class, because it could be of any extended type of this class, you need to explicitly allocate it to the right type. Because here we only have a single type for this class, I believe the other compilers make the assumption that's the one we want to allocate.

Changing to type makes it unambiguous.