Fortran interface to LoopControl broken in stable Carpet

Create issue
Issue #387 closed
Roland Haas created an issue

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 (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)


Comments (9)

  1. Roland Haas reporter
    • removed comment

    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.

  2. Erik Schnetter
    • removed comment

    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.

  3. Roland Haas reporter
    • removed comment

    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 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.

  4. Erik Schnetter
    • removed comment

    Please apply both patches.

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

  5. Roland Haas reporter
    • changed status to resolved
    • removed comment

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

  6. Log in to comment