Hello Ian, all,
And why would changing the default for VECTORISE_INLINE adversely affect these? I'm trying to understand Frank's statement that "people are bound to stumble over this when they try the released version". Frank, did you mean the soon-to-be (ET_2011_10) released version? Or the previously released version? If we change the default to VECTORISE_INLINE = no now, then no-one will run into this problem in the soon-to-be released version. Since the change to McLachlan didn't exist in the previously released version, it won't affect those.
Well someone might have non-simfactory options lists (those exist :-) ) and *that* one might say VECTORISE = yes which they want for their own private Kranc generated thorn. This way they would stumble across this.
I had wondered about that before: the method to support multiple orders of differentiation used in WeylScal4 and Kranc2BSSN.m was not used because it requires "unrolling" (exploding really) all choices for the combination of parameters at compile time? With lots of "schedule ... AS" statements the schedule does not look any different.
What happens if a user tries VECTORISE=yes on say a head of Ranger? Will they bring down the node or just have unexplainable compile errors in Kranc's generated code?
Yours, Roland