[Users] Cactus only using one "tags" string per group in interface.ccl?

[Ian Hinder]

On 20 May 2016, at 17:36, Bernard Kelly <physicsbeany at 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-183000D2.2, 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/01d8937b1fdd8a31060aeb4e387bc97bf5eeefe2/lib/sbin/interface_parser.pl?at=master&fileviewer=file-view-default#interface_parser.pl-896

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

-- 
Ian Hinder
http://members.aei.mpg.de/ianhin