presync fails to parse WaveToyOpenCL's schedule.ccl

[Roland Haas]

WaveToyOpenCL is part of the ET and compiled (and tested) on Blue Waters.

Right now it fails to compile with

CST warning in /mnt/a/u/staff/rhaas/ET_Next/arrangements/CactusExamples/WaveToyOpenCL/schedule.ccl (at  + 25)                                                                                                     -> Error read/write declaration in WaveToyOpenCL_Boundary schedule.                                   
[...]
CST warning in /mnt/a/u/staff/rhaas/ET_Next/arrangements/CactusExamples/WaveToyOpenCL/schedule.ccl (at  + 25)
  -> Error read/write declaration in WaveToyOpenCL_Boundary schedule.
     HINT: Did you mean WAVETOYOPENCL::scalar?

line 25 of the scehdule.ccl file in question is

WRITES: WaveToyOpenCL::Scalar

which (op to case) matches. Cactus variables and group mentioned in schedule.ccl are not normally case sensitive (the error goes away if I make “Scalar” → “scalar”).

Admittedly the whole CUDA and OpenCL support on BW may change since the new default compiler (gcc 6) is not supported by CUDA (needs 4.9 [which is a no-go] or 5 [maybe, would be compatible I think]).

[Steven R. Brandt]

The CCL files are sometimes case sensitive (user defined schedule groups, for example), and sometimes not (built in schedule bins). PreSync has (so far) required correct case on variable names. I could change this.

[Roland Haas]

I think it would be best if this was changed. Eg the STORAGE: Scalar code earlier in schedule.ccl is not case sensitive, so it would seem strange if READ/WRITE were case sensitive but STORAGE (and likely SYNC) was not. My guess would be that case sensitive parts are usually the schedule items (and the C code embedded in schedule.ccl), which required for C routines since the language itself requires this and apparently inherited by the user defined group.

[Steven R. Brandt]

I wander if sync is case sensitive? In any event, schedule groups could be forced to lower case before being written in C.

I can try to make it case insensitive. I think there was some problem with this, but I don’t remember.

[Roland Haas]

SYNC is definitely not case sensitive. In the same schedule.ccl file there is:

 SYNC:   Scalar

which compiles and works fine.

Note that the reason why schedule groups are case sensitive is very different from the one why scheduled routines written in C are. The latter are case sensitive since the linker symbol that is the C function preserves the case that is used in the C source code (which is not the case for Fortran scheduled function which are not case sensitive). Thus you get a link time error if you provide the wrong case for a C scheduled routine.ON the other hand, schedule group names never show up as a C identifier anywhere and are case sensitive because the flesh’s C code (in CCTKi_DoScheduleFunction) uses Util_GetHandle to get the group handle, which function uses strcmp on the handle name, which is the scheduled group name as it appears in schedule.ccl.

If there was a problem making READ / WRITE case insenstitive then that problem should be fixed.One problem that comes to mind would be generating variable names in DECLARE_CCTK_ARGUMENTS_Checked if one used the READ / WRITE strings in a case sensitive comparison against the full list that is currently used.

[Steven R. Brandt]

Yes, the case has to be “correct” in DECLARE_CCTK_ARGUMENTS_Checked, but that’s doable. I still think groups could be made case insensitive with a small effort.

[Roland Haas]

ok. Ah, I think I misunderstood you then. Yes, making groups case insensitive is likely doable. On the other hand: they never were, so making them now (and documenting so) requires that we check that they are case insensitive everywhere they are used, which is extra work which I did not want to advocate for . I was trying to push for READ / WRITE to be case insensitive since they are new and appear in places and have a feeling similar to SYNC which is not case sensitive. The schedule groups are a bit like scheduled function for which we already have both case sensitive (C functions) and insensitive (Fortran function) cases (and Cactus users trained to remember to make groups case sensitive). There would be an advantage of having them case insensitive in that at avoids scheduling in non-existing groups if one get the capitalization (eg MoL_Foo vs. MOL_Foo or EoS_Foo vs. EOS_Foo) wrong, which only results in a warning but no error (cannot result in error unfortunately since non-existent groups area feature).

[Steven R. Brandt]

Here’s a fix https://bitbucket.org/cactuscode/cactus/pull-requests/90/allow-case-invariant-variable-declarations/diff

[Steven R. Brandt]

What do you mean by “check they are case insensitive everywhere?” Regardless, the case sensitivity of groups is confusing. Even Ian Hinder thought it was insensitive about 5 years ago. But I agree it’s low priority.

[Roland Haas]

Fixed in git hash f5df9060 "Cactus: ignore case in READ / WRITE declarations" of cactus.