Add etrans

[samhatfield]

This PR adds the limited-area formulation of ecTrans, "etrans".

Actual work carried out by @ddegrauwe.

[wdeconinck]

This looks perfect now. Thanks @ddegrauwe for addressing my suggestions!

[samhatfield]

Note: PR #204 should be merged before this one.

[AlexandreMary]

Reminder that this (esp. commit 1bd0e01) requires fiat PR ecmwf-ifs/fiat#30

[wdeconinck]

Reminder that this (esp. commit 1bd0e01) requires fiat PR ecmwf-ifs/fiat#30

Thank you for the reminder!

[wdeconinck]

Apologies for overlooking this earlier: I don't agree with the move of ellips routines to fiat. I suggest to add them to the ectrans_common library instead, within ectrans repository. That also removes the dependency of merging ecmwf-ifs/fiat#30.

[AlexandreMary]

@wdeconinck the move of ellips was done for the needs of the externalisation of our FA format library (taken out of ifsaux), in the spirit of what has been done for ectrans. Indeed, FA calls ellips in order to determine the size of arrays for spectral fields, when reading spectral fields.
If we move it back to ectrans, it introduces a dependency of FA to ectrans, which is a bit far-fetched, especially as FA can be used in context that never deal with spectral fields (as if eccodes depended on ectrans for spherical harmonics fields).

Is that a design issue, I don't know, but one of the consequences of the desintrications of arpifs/trans/ifsaux. But maybe we can make that dependency optional there.
@ddegrauwe, @walidchikhi, any opinion on this ?

[wdeconinck]

Actually it seems ellips.F90 is still part of ectrans in this PR: src/etrans/cpu/internal/ellips.F90 so that this PR already should not depend on ecmwf-ifs/fiat#30 (?)

I suggest to add another copy of the ellips routine in the FA library. The routine is small and trivial.
Also better to change the symbol name within etrans as it is a private implementation detail, and avoids symbol clash with the other one.

[wdeconinck]

I agree that FA should not depend on ectrans, just as eccodes does not. eccodes however does reimplement some functions needed to support spectral fields, and does so in the C-language.

[AlexandreMary]

Actually it seems ellips.F90 is still part of ectrans in this PR: src/etrans/cpu/internal/ellips.F90 so that this PR already should not depend on ecmwf-ifs/fiat#30 (?)

I suggest to add another copy of the ellips routine in the FA library. The routine is small and trivial. Also better to change the symbol name within etrans as it is a private implementation detail, and avoids symbol clash with the other one.

It was removed in commit 1bd0e01 - but maybe reintroduced in one of the rebasing steps ???

[samhatfield]

I cherry picked this commit which (erroneously?) added ellips to the etrans/cpu/internal directory.

[ddegrauwe]

Yes, I reintroduced ellips.F90 in ectrans to be able to build without modifying the fiat version. Sorry about the confusion this caused.

Cleanest solution to me seems indeed to duplicate ellips in ectrans and in fa.

[lukasm91]

Note there are various mentions of FFT992 added in this commit. Can we drop those ifdefs? In general it would probably make sense to check the diffs of the files that now exist twice (like for example ftinvad_mod.F90 is likely a copy of ftinvad_mod.F90, with maybe a few, but only very few modifications)

[samhatfield]

Note there are various mentions of FFT992 added in this commit. Can we drop those ifdefs? In general it would probably make sense to check the diffs of the files that now exist twice (like for example ftinvad_mod.F90 is likely a copy of ftinvad_mod.F90, with maybe a few, but only very few modifications)

You mean eftinvad_mod.F90 looks like ftinvad_mod.F90?

I think the ff992 of trans/algor/fft992.F90 was previously used by etrans. Now the former has been deleted and we rely on FFTW only for ecTrans. I guess @ddegrauwe left in the #ifdef WITH_FFT992 for a reason, maybe to add fft992.F90 to etrans in future?

If there is no plan to use fft992 in etrans going forward, then yes I suggest we remove all instances of #ifdef WITH_FFT992.

[ddegrauwe]

Exactly. It hasn't been decided/agreed in our community whether we can get rid of FFT992. That's why I kept these calls under an #ifdef. If this is annoying, I guess it can be removed alltogether: putting it back isn't such a big issue.

About the duplication of routines: most routines for the global case have a LAM counterpart (e.g. ftinvad_mod vs eftinvad_mod). While the functionality is the same, some details may be different. Where possible, duplication is avoided and global routines are called directly from the LAM code (e.g. ftinv is called from eftinv_ctl).