Modules are suffixed `_dp` (or sp) and not found

[AlexandreMary]

Trying to switch from an older version to 1.6.2, I fall upon an issue:
modules (.mod) are suffixed with _dp (e.g. trltom_mod_dp.mod) and hence not found when trying to compile external code that uses that module (with gmkpack).

[samhatfield]

Hey @AlexandreMary. I've not used gmkpack before but I'm guessing it's similar to CMake. Is it not possible to simply choose either the _dp or _sp version depending on whether you are building a double- or single-precision binary?

[AlexandreMary]

Yes we do choose, but I don't understand why the name of the modules changes ?
In the code we still would have USE TRLTOM_MOD, without specifying the precision

[samhatfield]

When you say "the code", do you mean in ecTrans, or outside of ecTrans? If you mean in ecTrans, "technically", there is no USE TRLTOM_MOD in any built object code. As part of the build process, we rename all of these symbols depending on which backend we are building (cpu-sp, cpu-dp, gpu-sp, gpu-dp). So, the dp cpu library will say USE TRLTOM_MOD_dp, and likewise _sp for the sp library. Here's an example:

➜  build $ ag 'TRLTOM_MOD'
src/trans/cpu/generated/ectrans_dp/internal/ltdir_ctl_mod.F90
48:USE TRLTOM_MOD_dp      ,ONLY : TRLTOM

The long term goal is to be able to link a program against all backend libraries and then choose which one you want at runtime (e.g. CALL SETUP_TRANS(BACKEND="SP GPU").

We thought this was safe, because any subroutines in the internal directory shouldn't be called by anything outside of ecTrans. In fact there were a couple of naughty cases in arpifs where we called an ecTrans internal subroutine, but fortunately it was straightforward to delete them. Going forward, in arpifs we won't allow internal subroutines of ecTrans to be called by anything other than another internal subroutine or one of the external subroutines. It's an attempt at keeping ecTrans as a neat, isolated library.

What I think you're saying is that you link a program (ARPEGE maybe?) against ecTrans and you're using ecTrans internal subroutines directly in ARPEGE code, like TRLTOM. If so, is it possible to avoid that, by using one of the existing externals? If not, we can come up with another fix.

Happy to have a video call some time if it's easier.

[AlexandreMary]

OK, thanks for the explanation, indeed, the type of issues I am facing here is a call to "internal" routines from an IAL (ifs-source) routine, in
etrans/programs/trinfo.F90 only for the modules SU[E]MPLAT_MOD

How should it be fixed ?

[samhatfield]

Hmm. I wonder. Are you building the files in ifs-source/etrans/{external, module}?

I think there's no problem with SUMPLAT_MOD (even if it's not recommend to call internal routines).

To use SUEMPLAT_MOD you will need etrans of course. If you are building the version of etrans bundled in ifs-source (ifs-source/etrans/{external, module etc.}) then that won't work. That's an old version of etrans, which isn't aware of these new changes to ecTrans.

Is that right? If so can you change to using this etrans?

It's hard for me to say exactly what to do as I'm not familiar with gmkpack. But ideally we wouldn't have ifs-source/etrans at all (apart from the programs directory).

Or have you already moved to using etrans provided by ecTrans?

[AlexandreMary]

Yes, we have moved to the etrans from ecTrans, only remain programs in the ifs-source etrans/
(this is CY50T1 or more exactly the merge of CY50T1 with CY50R1_20251007)

Just met the same issue (with another module) with other program aladin/programs/[un]holo.F90 - there may be a few more...

(And indeed, sumplat_mod.mod is available in non-dp/sp suffixed so not a problem)

[samhatfield]

I noticed that etrans doesn't yet have a "common" library, like with ecTrans. Everything is either in the _dp or _sp libraries. So, unlike with SUMPLAT_MOD, you need to specify which precision you want for SUEMPLAT_MOD. We can start by creating a common library for etrans. That will allow you to use SUEMPLAT_MOD from IAL code as-it-is. You'll need to put etrans_common.so on your link line of course.

As for other calls to ecTrans/etrans internal subroutines in IAL, we need a proper approach for gmkpack. Unless you feel confident enough to tackle it, I think we need to bring someone on board who knows the nuts and bolts of gmkpack.

[AlexandreMary]

Yes indeed, we will need some adaptations of gmkpack to cope with that (plus the fact that the .h are also split between sp and dp).
@marsdeno @wdeconinck This kind of changes should have been discussed with us before being implemented.

[marsdeno]

Yes, point taken.

[RyadElKhatibMF]

for now, is it possible for us to just stay on an older version of ectrans ?

[AlexandreMary]

Well in CY50R1 (hence pre-CY51) there are calls to new subroutines not present in the version of ectrans we were using until CY50T1.

[RyadElKhatibMF]

Then the proper course of action should be to revert the problematic modification.
(as you did for mine ;-)