allow paramters in STORAGE statements

[Roland Haas]

the attached patch allows constructs such as:

STORAGE metric[timelevels]

instead of the currently used and more cumbersome:

if(timelevels == 1) { STORAGE metric[1] } else if(timelevels == 2) { ... }

The full set of Curie test suites pass (on my workstation usin gcc 4.6, OpenMP and 2 processes) with just that patch and with the second patch to GRHydro that actually uses the new facilities

Keyword:

[Erik Schnetter]

Roland, thanks a lot for this patch! I am highly surprised that such a simple implementation would work; I always assumed that one would also need to explicitly access the parameter values in the auto-generated code.

Approved, under the condition that you also update the documentation in the user's guide, both a general description and an update of the CST syntax description. In particular, the schedule allows parameter specifications using the thorn::name scoped syntax, which is presumably not possible in your implementation, so this needs to be documented.

[Roland Haas]

I am not quite sure I fully understood the scoped syntax thorn::name issue. The patch requires that parameters used are accessible to the thorn and that the parameter is named as in C functions (ie. as in an "if(<expression>) { ... }" statement in the schedule.ccl file. I have put text to this effect in all places in UsersGuide.tex and ReferenceManual.tex where the word STORAGE appears (same text all the time). Version 2 of the patch also contains one more test: Before only STORAGE statements inside of SCHEDULE blocks were checked for an invalid number timelevels at runtime, but not those at file level (which are the majority). As this affects the flesh and I do not have commit rights there, someone else will have to commit the patch, please. The committer will also have to regenerate the PDF version of the documentation (since I do not know how to include binary files in a subversion diff).

[Erik Schnetter]

One can use parameters in interface.ccl, and there it is possible to use the "thorn::parameter" syntax. I do not know whether it is necessary to share the parameters -- presumably this should be the case.

I have briefly tested and applied your patch. Thanks again!

If you want, you could also add a thorn to CactusTest / modify a thorn in CactusTest to test this new syntax.