[Users] SummationByParts c_file_processor issues

Roland Haas rhaas at illinois.edu
Fri Feb 17 20:50:05 CST 2023


Hello Samuel,

Would this be using an "unusual" compiler? Namely the IBM compiler?

Cactus expects that Fortran adds at least one underscore to function
names. That is a function visible in Fortran as "Foo" is visible to the
linker (and C code) as Foo_.

If that is not the case then there can be a conflict in case (against
what the docs say) there are:

void CCTK_FNAME(foo)(int *);
void foo(int);

with the assumption that they are different (happens if eg the latter
one is called by the former to provide its functionality).

Fixes:

* make your compiler add at least one underscore (for the IBM compiler
  you may have to read the docs)
* name the functions CCTK_FNAME(Foo)(int *) and Foo(int). This will
  work even without underscores since Fortran, being case insensitive,
  internally converts all names to lowercase (or uppercase, or
  thechnically lOwErCaSe would also work as long as the pattern is
  unique).

Also note that CCTK_FNAME can *only* be used in compiled files (*.c and
*.cc files) not header files (*.h) even if the header are included in c
files (all of them are anyway...).

See:
http://einsteintoolkit.org/usersguide/UsersGuide.html#x1-130000C1.9.4

--8<--
void CCTK_FCALL CCTK_FNAME(<routine name>)(int *ierr, <argument list>)
<rewrite routine code, or call C routine itself>

The convention used in Cactus, is that <routine name> be the same as any C routine name, and that this is mixed-case. The macros change the case and number of underscores of the routine name to match that expected by Fortran.
--8<--

Yours,
Roland

> For the compiling gurus:
> 
> I've been working towards finalizing the FUKA importer build system for inclusion into the ETK and I've recently added additional thorns to the build list to run the test par. For completeness, I'm compiling in the following way:
> 
>     yes | make test-config THORNLIST=thornlist/test.th options=test.cfg;
>     make test:
> 
> Currently, all thorns compile successfully except for SummationByParts which gives the following error:
> 
>     /home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src/get_offset.c:49:17:
>     error: redefinition of ‘get_shiftout’
>         49 | void CCTK_FCALL CCTK_FNAME(get_shiftout)( const
>     CCTK_POINTER_TO_CONST cctkGH_,
>            |                 ^~~~~~~~~~~~
>     /home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src/get_offset.c:11:6:
>     note: previous definition of ‘get_shiftout’ with type ‘void(const
>     void * const,  CCTK_INT4 *)’ {aka ‘void(const void * const,  int *)’}
>         11 | void get_shiftout ( const CCTK_POINTER_TO_CONST cctkGH_,
> 
> What appears to be happening is that the c_file_processor.pl is not handling the generation of creating a fortran function in place of CCTK_FNAME so far as I understand it.  For instance, if I check the `Cactus/configs/test/build/SummationByParts/get_offset.c` file, the CCTK_FNAME statement is still there.  Conversely, if I check `Cactus/configs/test/build/Boundary/FlatBoundary.c` which also uses CCTK_FNAME, these statements have been correctly removed by the pre-processor.
> 
> Oddly enough, if I run `make test --just-print` I obtain the following which suggests that it is at least executing the processor correctly.
> 
>     Checking status of thorn SummationByParts
>     if [ ! -d ./ ] ; then mkdir -p ./ ; fi
>     cd ./ ;
>     make CCTK_TARGET=make.checked
>     TOP=/home/user/lib/ETKREL/Cactus/configs/test
>     CONFIG=/home/user/lib/ETKREL/Cactus/configs/test/config-data
>     SRCDIR=/home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src
>     THORN=SummationByParts USESTHORNS="" -f
>     /home/user/lib/ETKREL/Cactus/lib/make/make.subdir{if test yes =
>     'yes'; then echo '#line 1
>     "'/home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src/get_offset.c'"';
>     fi;
>          cat
>     /home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src/get_offset.c;
>     } | perl -s
>     /home/user/lib/ETKREL/Cactus/lib/sbin/c_file_processor.pl
>     -line_directives=yes
>     -source_file_name=/home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src/get_offset.c
>     /home/user/lib/ETKREL/Cactus/configs/test/config-data > get_offset.c
>     echo COMPILING CactusNumerical/SummationByParts/src/get_offset.c
> 
> I have compared the above to the compilation of Boundary/src/FlatBoundary.c which compiles successfully and also includes the generation of a number of Fortran functions using CCTK_FNAME.  So far, no discrepancies have been found that would highlight why summationbyparts is failing.
> 
> I will continue to try and resolve this, but I hope someone with more experience with the pre-processors will be able to shed some light on the issue.
> 
> Cheers,
> 
> Samuel



-- 
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://keys.gnupg.net.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20230217/90499eae/attachment-0001.bin 


More information about the Users mailing list