rdwr.pl accepts inconsistent read / write statements for a function scheduled multiple times

[Former user]

SphericalSurface's schedule.ccl contains:

SCHEDULE SphericalSurface_Set AT basegrid BEFORE SphericalSurface_HasBeenSet
{
  LANG: C
  OPTIONS: global
  READS: SphericalSurface::sf_nphi #scalar
  READS: SphericalSurface::sf_ntheta #scalar
  READS: SphericalSurface::sf_coordinate_descriptors #scalar
  WRITES: SphericalSurface::sf_active(everywhere) #scalar
  WRITES: SphericalSurface::sf_valid(everywhere) #scalar
  WRITES: SphericalSurface::sf_info(everywhere) #scalar
  WRITES: SphericalSurface::sf_origin(everywhere) #scalar
  WRITES: SphericalSurface::sf_radius(everywhere) #scalar
} "Set surface radii to be used for initial setup in other thorns"
[...]
SCHEDULE SphericalSurface_Set AT poststep BEFORE SphericalSurface_HasBeenSet
{
  LANG: C
  OPTIONS: global
} "Set surface radii"                                                                                   

ie the same function SphericalSurface_Set is scheduled multiple times. However only one of them declares reads and writes.

Most likely rdwr.pl should at the very least output a warning about this, and if there were actually read / write statements in both schedule blocks (and they were not identical) it should abort.

Even when one is empty it may be good to abort since otherwise there are at least two ways this could be interpreted 1. "use the one with read / write to define DECLARE_CCTK_ARGUMENTS_Checked" (ie use the more specific one) or 2. "use the first one found". 2. would be odd since nothing else in schedule.ccl is order dependent and in fact schedule.ccl is there exactly so that there is no global serial writeup of how to exectuate things.

[Roland Haas]

After some (offline) discussion with @Steven R. Brandt and some thinking about this, it turns out that rdwr.pl must accept inconsistent read / write statements and, since there is only one DECLARE_CCTK_ARGUMENTS_Foo per function Foo, the generated macro must use the union of the read / write statements.

This is because there can be (will be most likely) schedule.ccl that look like so:

if(evolve_Y_e) {
  schedule GRHydro_Con2Prim
  {
    READ: rho Y_e
  }
} else {
  schedule GRHydro_Con2Prim
  {
    READ: rho
  }
}

for codes where the state vector depends on runtime parameters.

[Ian Hinder]

Does the flesh/driver set the unread variables to null pointers, or is that done by the macro?

[Steven R. Brandt]

@Ian Hinder the driver sets the undeclared pointers to null if the psync_error parameter in the flesh is set to true. Otherwise, it behaves as it always has.

[Ian Hinder]

In the above example, would the driver set Y_e to null when evolve_Y_e = false?

‌