Correct OptionsType subroutine's this parameter intent; Use brew --prefix to resolve the correct platform specific brew prefix

[aaraney]

Change:

• Correct OptionsType subroutine's this parameter intent to inout. aarm gfortran compilers appear to be more strict and do not generate the same symbols as other compilers. This results in linking errors (see comments below). Similar to Compile error on Mac M3 chipset snow17#37

CI:

On intel macOS, brew installs into /usr/local
On apple silicon, brew installs into /opt/homebrew

Use brew --prefix to resolve the right brew prefix in a platform independent manor

[aaraney]

The macOS Testing and Validation action seems to be failing b.c. of a linking issue

gfortran -o noah_owp_modular.exe -I../driver -I../src ../src/ErrorCheckModule.o ../src/NamelistRead.o ../src/ParametersRead.o ../src/LevelsType.o ../src/DomainType.o ../src/OptionsType.o ../src/ParametersType.o ../src/ForcingType.o ../src/EnergyType.o ../src/WaterType.o ../src/WaterModule.o ../src/CanopyWaterModule.o ../src/SnowWaterModule.o ../src/SnowWaterRenew.o ../src/SnowLayerChange.o ../src/SoilWaterModule.o ../src/SoilWaterRetentionCoeff.o ../src/SurfaceRunoffInfiltration.o ../src/SurfaceRunoffModule.o ../src/SoilWaterMovement.o ../src/SubsurfaceRunoffModule.o ../src/AtmProcessing.o ../src/ForcingModule.o ../src/InterceptionModule.o ../src/ThermalPropertiesModule.o ../src/AlbedoModule.o ../src/ShortwaveRadiationModule.o ../src/PrecipHeatModule.o ../src/EtFluxModule.o ../src/SnowSoilTempModule.o ../src/EnergyModule.o ../src/UtilitiesModule.o ../src/DateTimeUtilsModule.o ../src/RunModule.o ../driver/OutputModule.o ../driver/NoahModularDriver.o ../driver/AsciiReadModule.o ../bmi/bmi_noahowp.o ../bmi/bmi.o -L/opt/homebrew/lib -lnetcdf -lnetcdff
Undefined symbols for architecture arm64:
  "_is_recursive.0.2", referenced from:
      ___optionstype_MOD_inittransfer in OptionsType.o
      ___optionstype_MOD_inittransfer in OptionsType.o
      ___optionstype_MOD_inittransfer in OptionsType.o
  "_is_recursive.2.1", referenced from:
      ___optionstype_MOD_initdefault in OptionsType.o
      ___optionstype_MOD_initdefault in OptionsType.o
      ___optionstype_MOD_initdefault in OptionsType.o
  "_is_recursive.4.0", referenced from:
      ___optionstype_MOD_init in OptionsType.o
      ___optionstype_MOD_init in OptionsType.o
      ___optionstype_MOD_init in OptionsType.o
ld: symbol(s) not found for architecture arm64
collect2: error: ld returned 1 exit status
make[1]: *** [noah_owp_modular.exe] Error 1
make: *** [all] Error 2

Im not sure if this is a platform specific issue or not. Going to try with an intel macOS runner to test that theory.

[aaraney]

Getting the same issue on intel macOS.

https://github.com/NOAA-OWP/noah-owp-modular/actions/runs/10742422551/job/29795011245?pr=116#step:5:1162

[madMatchstick]

@aaraney - note that atm the add-to-project action will fail for PRs from forked repos. Thanks @SnowHydrology for pointing this out!

[aaraney]

I think i've figured out what the issue is and it actually appears to be a bug in the source code. All of the OptionsType subroutines's this parameters where incorrectly marked as intent(out). These should have been marked as intent(inout).

[SnowHydrology]

Cross-linking this same issue from Snow-17 in case it's of use: NOAA-OWP/snow17#37

[madMatchstick]

Thanks @aaraney for digging into this.

Noting for my own reference that this fixes the macos testing and validation workflow but the macos ngen CI still fails due to fortran compiler issues sourced from another workflow, module_integration here.

[aaraney]

@madMatchstick, once NOAA-OWP/ngen#880 has merged I expect that the tests will pass. At least, I wouldn't expect them to fail in the way they are now.