On 20 May 2016, at 17:36, Bernard Kelly physicsbeany@gmail.com wrote:
Hi.
I only just found out that these two interface.ccl declarations are *not* equivalent:
- tags='checkpoint="no" Prolongation="none"'
tags='tensortypealias="Scalar" tensorweight=0 tensorparity=1'
- tags='checkpoint="no" Prolongation="none" 'tensortypealias="Scalar"
tensorweight=0 tensorparity=1'
Both compile, but in the first case, the contents of the first "tags" string is ignored (I realized this only when I was getting crashes from CarpetLib's ggf.cc on attempted prolongation).
So given that only one tags value is being used for each group, Is there a reason why the compilation stage SHOULDN'T flag/fail on a repeated tags definition like the first example? Since it didn't, I just assumed it was concatenating the two strings and using all the info.
[Yes, I know it's silly to have two assignments where one will do, but as often happens, I inherited some code that did it.]
[I'm still using ET_2015_05 for this, in case anything's changed.]
Hi Beanie,
According to https://einsteintoolkit.org/documentation/UsersGuide/UsersGuidech12.html#x17..., the format is
[<access>:]
<data_type> <group_name>[[<number>]] [TYPE=<group_type>] [DIM=<dim>] [TIMELEVELS=<num>] [SIZE=<size in each direction>] [DISTRIB=<distribution_type>] [GHOSTSIZE=<ghostsize>] [TAGS=<string>] ["<group_description>"] [{ [ <variable_name>[,]<variable_name> <variable_name> ] } ["<group_description>"] ]
and there is no mention of allowing multiple TAGS entries. I would say it is a bug that the parser allows this, and certainly a bug that it silently ignores the first one.
The code that looks like it handles this is in Cactus/lib/sbin/interface_parser.pl, around line 896:
https://bitbucket.org/cactuscode/cactus/src/01d8937b1fdd8a31060aeb4e387bc97b...
%options = SplitWithStrings($options_list,$thorn); # Parse the options foreach $option (sort keys %options) {
... elsif($option =~ m:TAGS:i) { if($options{$option} =~ m/\s*^['"](.*)['"]$/) { $options{$option} = $1; }
$options{$option} =~ s/\/\\/g; $options{$option} =~ s/"/\"/g;
$interface_data_ref->{"\U$thorn GROUP $current_group\E TAGS"} = $options{$option}; }
So there is no check that options aren't specified twice, and no attempt to merge subsequent settings.