Fortran interface to LoopControl broken in stable Carpet

[Roland Haas]

the Fortran interface no longer matches the C interface. When the C routines are called from Fortran then paramters are missing and the types for lt_statmap etc. in loopcontrol.F90 do not match loopcontrol.h anymore. Right now it segfaults.

The attached patch brings the Fortran interface back into sync with the C interface. Tested with the attached modified version of GRHydro.

Also requires a patch to f_file_processor.pl (separate ticket, to be created).

The same issue (Fortran interface not being aware of the vectorisation seems to apply to the Mercurial version as well)

Keyword:

[Roland Haas]

f_file_processor.pl ticket is ticket #388

[Erik Schnetter]

Please apply this patch (to both versions of Carpet if possible).

[Roland Haas]

I applied th patch to the stable version. It does not apply cleanly to the Mercurial version (some things are apparently handled differently). I tried to understand what the Hg version of loopcontrol.h does, but do not understand the following lines (numbers are line numbers, the file is loopcontrol.h)

256: int const lc_di = (di_); \ /*...*/ 291: int const lc_ipos = \ 292: lc_imin + lc_lc.ilsh * (j + lc_lc.jlsh * k); \ 293: int const lc_ioffset = (lc_ipos & - lc_di) - lc_ipos; \

I am not sure what "(lc_ipos & - lc_di)" does (nor does gcc here seem to accept this construct [with our without -std=c99]). Any help would be welcome.

[Erik Schnetter]

This expression rounds down to the next multiple of lc_di, assuming that lc_di is a power of 2. This is necessary for vectorisation; for example, a 2-vector of an 8-byte quantity can only be efficiently loaded and stored if it is located at an address that is a multiple of 16.

If lc_di is a power of 2, then -lc_di is a mask that sets some of the lowest bits to zero, and lc_ipos & -lc_di is the rounded-down multiple of lc_di. The difference to lc_ipos is then the offset to this location.

The expression lc_ipos & -lc_di is in this case equivalent to lc_ipos/lc_di*lc_di, but is evaluated much faster.

This is standard C and C++. The inline variable declarations may require choosing C99 semantics.

Without vectorisation, lc_di is 1, and lc_ioffset is always 0.

[Roland Haas]

Aha, I binary "&". I was somehow fixated on "&" being only the address operator. Thank you. Tells me I should not look at unfamiliar code late at night. The error I got was actually caused by me using dots "." instead of commas "," in a statement later on in my test code, sigh.

I created a patch for the Mercurial version and attached to this ticket, since the original patch does not apply. Tested with GRHydro's Con2Prim and the GRHydro_test_tov_ppm_ML testsuite on gcc 4.5 and Intel 11.1 (and the v2 version of the f_file_processors.pl script).

The patch is independent of the first one, it was created by copying the C loopcontrol.h macros and converting each line to the corresponding Fortran code.

Also attached is a patch to add a sanity check (and a non-fatal warning) to CCTK_Startup.

[Erik Schnetter]

Please apply both patches.

I would make it a fatal error if the C and Fortran sizes differ.

[Frank Löffler]

Roland - can you commit that, please?

[Roland Haas]

changes to Hg were committed on Monday, git was done some days earlier, I forgot to close the ticket.