Potential IFX issue

[emorway-usgs]

Describe the bug
I'm wondering if CI checks whether IFX is working with the latest source code? Something seems off with the latest IFX compiler. Most, but not all, autotests seem to fail with an executable compiled by IFX. The message is consistently: "A pointer passed to DEALLOCATE points to an object that cannot be deallocated." Pasting a screen grab below. Given the extensive number of builds that are tested with CI, it seems like this might be an issue with IFX rather than the source code. The autotests that fail using an IFX executable pass if I replace the executable with the most recent exe from the nightly builds ("win64.zip"). If I build a debug version using the IFX compiler, it does not produce the error, making it difficult to track down (in Windows) which pointer it doesn't seem to like.

To reproduce
Using the most recent BaseKit and HPC Build Kits available with OneAPI

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots

Environment

• Operating system: Windows 11
• MODFLOW 6 version: Building from src locally
• Intel Fortran Compiler 2025.0

[langevin-usgs]

Even though you are using a release build, you may still be able to turn on debug and traceback information from the visual studio fortran options in the hopes that you can either debug the release version or see what line number is causing the failure. Just a thought. Would be nice to get to the bottom of this. Note that there are recent changes in the memory manager by @Manangka for deallocation -- not sure if this is related.

[langevin-usgs]

I just came across this issue and have a bit more information. The following is the error that I get.

    Solving:  Stress period:     1    Time step:    10
forrtl: severe (173): A pointer passed to DEALLOCATE points to an object that cannot be deallocated
Image              PC        Routine            Line        Source
mf6d.exe           00FD1F66  Unknown               Unknown  Unknown
mf6d.exe           005AC134  _MEMORYTYPEMODULE         150  Memory.F90
mf6d.exe           003B95BF  _MEMORYMANAGERMOD        2449  MemoryManager.f90
mf6d.exe           0033D1D9  _RUNCONTROLMODULE          59  RunControl.f90
mf6d.exe           00323B3C  _MF6COREMODULE_mp         242  mf6core.f90
mf6d.exe           003210E5  _MF6COREMODULE_mp          58  mf6core.f90
mf6d.exe           0032103F  _MAIN__                    11  mf6.f90
mf6d.exe           010709CF  Unknown               Unknown  Unknown
mf6d.exe           010716A3  Unknown               Unknown  Unknown
mf6d.exe           01071577  Unknown               Unknown  Unknown
mf6d.exe           0107141D  Unknown               Unknown  Unknown
mf6d.exe           01071708  Unknown               Unknown  Unknown
KERNEL32.DLL       76CDC1E8  Unknown               Unknown  Unknown

Memory.F90 shows the following. Line 150 corresponds to the gfortran < 13 deallocate line. Is it possible that the directives are not set up correctly or that GFORTRAN is not set right? I think maybe the first deallocate should only be for the gfortran versions (and not ifx or others)?

#if __GFORTRAN__  && ((__GNUC__ < 13) || (__GNUC__ == 13 && __GNUC_MINOR__ < 3))
      if (this%master) deallocate (astr1d)
#else
      if (this%master) deallocate (this%astr1d)
#endif

[Manangka]

@emorway-usgs Which ifx compiler are you using? I'm trying to reproduce it on my machine but with ifx "Version 2025.0.4 Build 20241205" all the tests succeed.

Edit:
I'm testing it on windows

Edit2:
I just saw on your attached image that we are using the same compiler version

[Manangka]

After doing a full clean build i do get failing tests. About 20 of them. And they only occure during a release builf with ifx.
However they tests that are failing give a different error message on my machine:

[wpbonelli]

@Manangka windows / intel 2025.0 release build fails the same tests in CI.

https://github.com/MODFLOW-USGS/modflow6/actions/runs/13113756240/job/36583144940#step:16:7604

I'll take a look at the PRT snapshot tests. Can probably either tweak floating point options for ifx in meson.build or relax the comparisons. Some of the other ones also look like comparison failures.

No idea why we are seeing different results than @langevin-usgs and @emorway-usgs.

[Manangka]

Those are indeed the same failing tests as I have.

The failing sfr/sfe tests seem to be caused by commit 0247b7e. When reverted they succeed again.

[Manangka]

@emorway-usgs and I just had a call and we found out what is causing the differences in error.
He is building MODFLOW using visual studio while I'm building it through Meson. As a consequence compiler arguments set in meson are not in sync with those of the vsproj files. In this case it is missing the /fpp argument that enables the preproccessor.
After setting both ways of building produces the same errors

I will create a PR to fix the vsproj settings

[langevin-usgs]

Sorry @Manangka, I should have thought of that. I was also building with vsproj, so that explains why the directive wasn't working correctly for me -- the source file wasn't being preprocessed.