Open kawechel opened 1 month ago
Hi @kawechel, thanks for the report. The fundamental issue here is that Caliper's MPI interception mechanism only supports the C MPI API but not the Fortran MPI API. That's why it doesn't capture and trigger a flush at MPI_Finalize()
as it should. It works with the programmatic configuration since in this case the program calls the flush explicitly.
You can add call cali_flush(0)
before the MPI finalize call, which would trigger a flush for Caliper's "default" channel, which runs what is set through the CALI_SERVICES_ENABLE
environment variable. I'm planning to update that function to also include configurations set with the CALI_CONFIG
variable. This should solve the flush problem. However, due to the lack of Fortran MPI support functionality like mpi-report
that depends on MPI interception will still be limited.
Thanks for the advice, that all makes sense. I managed to get things to work using command line flags, which is good enough for our purposes. But I can confirm that inserting call cali_flush(0)
just before MPI_Finalize
fixes the environment variables approach as well.
Summary of the problem: A minimal Fortran + MPI code throws the Caliper error
MPI is already finalized. Cannot aggregate output
at runtime.How to reproduce: I have modified the example Fortran code that ships with Caliper (v2.12.0-dev under
examples/apps/fortran-example.f
) to be a minimal MPI code. I build the code with gfortran 11.4.0 and OpenMPI 4.1.2:I set both
CALI_CONFIG
andCALI_SERVICES_ENABLE
(though I realiseCALI_CONFIG
takes precedence andCALI_SERVICES_ENABLE
is not strictly needed):Running the test code fails as follows:
However, if I unset the
CALI_XXX
environment variables and set the services programmatically, everything works as expected. I.e. I modify the code to useadd()
and remove the section that reads the command line arguments:Followed by unsetting the environment variables:
When I run the code, the behaviour is correct:
Can you please shed some light on this? For Caliper to be a long-term solution for us, we need to be able to define profiling reports at runtime (via environment variables ideally), and currently we are restricted to compile time because we need to define everything in the code. Hopefully you are able to reproduce the issue given the example above and suggest a fix.