Multipole: turn on CI test

[lwJi]

No description provided.

[rhaas80]

Why are the data files being updated? Shouldn't the result be the as before? If not then a comment in the commit message would be good explaining why the change is expected.

[rhaas80]

Are these the number the same as for the Carpet based thorn? The file extensions are different and the commit that introduces them does not really tell anything about whether they have ever been compared to a "known good" version.

[lwJi]

Why are the data files being updated? Shouldn't the result be the as before? If not then a comment in the commit message would be good explaining why the change is expected.

The change is caused by the bug fix in Z4c

[lwJi]

Are these the number the same as for the Carpet based thorn? The file extensions are different and the commit that introduces them does not really tell anything about whether they have ever been compared to a "known good" version.

It was not copied from Carpet. I made it up from scratch. I just want have something that tell me I didn't change the code when I commit

[rhaas80]

ok. For the change in values for Multipole's test it may then be good to add something along the lines of:

Regenerate test data after commit bd461ad "Z4c: fix bug related to the misuse of sym_symm"

so that people can correlate the change in Multipole with the source of the changed values.

Best to give both the git hash and the subject line in case we ever move to a different version control system and the git hashes become meaningless (we moved from svn to git for some repo and thankfully git-svn preserves the svn revision numbers as part of the git commit message, but one would not want to rely on that if possible).

[lwJi]

ok. For the change in values for Multipole's test it may then be good to add something along the lines of:

Regenerate test data after commit bd461ad "Z4c: fix bug related to the misuse of sym_symm"

so that people can correlate the change in Multipole with the source of the changed values.

Best to give both the git hash and the subject line in case we ever move to a different version control system and the git hashes become meaningless (we moved from svn to git for some repo and thankfully git-svn preserves the svn revision numbers as part of the git commit message, but one would not want to rely on that if possible).

Done