[Users] compiler warning for McLachlan

[Ian Hinder]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 27 Sep 2011, at 17:33, Roland Haas wrote:

> 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.

If we change the default, then the default will be VECTORISE_INLINE = no.  We have to have a default, and it's not clear which is better.  Vectorisation is new in this release of the ET, so no one using a previous release should be affected.  We know that McLachlan prefers VECTORISE_INLINE = no for high order differencing, otherwise the compiler takes too much memory.  So I say we should set the default to the only thing we know is a definite improvement for the thorns in the ET.  

> 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.

?  The addition of this feature of Kranc was intended to avoid this proliferation of parameterised calculations.  I'm not sure what you are trying to say...

> 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?

If they have VECTORISE = yes (the proposed default for the new release of the ET) and VECTORISE_INLINE = yes (the current default, which I propose should be changed to "no"), and they try to compile McLachlan, the behaviour will be as Frank saw, which is that you get a warning and the compiler runs out of memory.  If the Ranger head node is configured such that a user can bring down the system by running a program which takes up a lot of memory, then the head node will go down.  This is common for default linux installs (I don' t know why), but Ranger has a ulimit setting of 8 GB for virtual memory, so I think the process will be terminated when it uses more than 8 GB, which is a sensible precaution for a production system.

- -- 
Ian Hinder
ian.hinder at aei.mpg.de

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAk6B8KsACgkQF1LN8Zj+CeiTSgCfX6agIgXK+acLBYEk7fLw/BN4
RowAn3+G55l44YGfuZMvF79L4blUc/Cf
=s6ku
-----END PGP SIGNATURE-----