Fortran interface to LoopControl broken in stable Carpet

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

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

  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