Add LTS CMake Option in GenHarmBase Executables

[AlexCarpenter46]

Proposed changes

Adds an option to either build in LTS or GTS for the executables that use GeneralizedHarmonicBase

Upgrade instructions

Code review checklist

• The code is documented and the documentation renders correctly. Run
  make doc to generate the documentation locally into BUILD_DIR/docs/html.
  Then open index.html.
• The code follows the stylistic and code quality guidelines listed in the
  code review guide.
• The PR lists upgrade instructions and is labeled bugfix or
  new feature if appropriate.

Further comments

[AlexCarpenter46]

If we don't use or build EvolveGhCce or EvolveGhCcm can I delete them in this PR (saw a comment on this in slack)?

[geoffrey4444]

Do you understand why the tests fail? Let's discuss if needed!

[AlexCarpenter46]

Okay, got all the tests timing out figured out and clang-tidy so I think this is ready for a review :)

[knelli2]

Do you still need this long of a timeout now that you decreased the slab size?

[AlexCarpenter46]

ah no, after looking at how long it took the tests in github, it seems 15 seconds should be good

[AlexCarpenter46]

Squashed the timout change in :) @knelli2

[wthrowe]

You shouldn't restrict the slab size to line up with observations, particularly not to something this small. If you need more frequent output use dense output instead of forcing extra RHS evaluations.

[AlexCarpenter46]

This was sort of arbitrarily chosen to make the test not take forever. This wouldn't be very realistic for an actual evolution. Maybe I should change the comment to make it clear that you should change the slab size if you're using this yaml or use dense output if you want more frequent output.

[wthrowe]

Yeah, having the value small for the test is fine, but the comment shouldn't recommend doing observations that way.

[wthrowe]

Most of the observations in this file are based on the slab size, so you've decreased the amount of output by a factor of 50 here. For the constraint norms that might be fine, but it's probably not what you want for the actual data observations.

[AlexCarpenter46]

This was taken to match the inspiral.yaml and I assumed we'd want a similar amount of output during the ringdown.

[wthrowe]

I don't know. The dynamical timescales are shorter, so maybe people want more data? @geoffrey4444 or someone who actually analyzes runs want to weigh in?

[geoffrey4444]

Here is what I actually did in the ringdown that worked; I'd suggest something similar in the pipeline:

Evolution:
  InitialTime: 0.0
  InitialTimeStep: 0.0002
  InitialSlabSize: 0.1
  StepChoosers:
    - Increase:
        Factor: 2
    - ErrorControl:
        AbsoluteTolerance: 1e-10
        RelativeTolerance: 1e-8
        MaxFactor: 2
        MinFactor: 0.25
        SafetyFactor: 0.95
  TimeStepper:
    AdamsBashforth:
      Order: 4

[geoffrey4444]

I don't have any actual successful ringdown runs with global time stepping, so I don't have an opinion on good choices for that case

[wthrowe]

How often do you do observations? That's more what I'm worried about here.

[knelli2]

I don't think we know exactly how often we want to do observations. 0.1 for a slab size seems reasonable for now. We'll probably have to revisit this later though as we do more testing and actually do a successful ringdown with the pipeline. I think the more important part of this PR is the switch to LTS itself.

[wthrowe]

I'm fine with the settings in the files, but I still don't want comments telling people to shrink the slab to observe more.

[knelli2]

@wthrowe So what is your suggestion if more frequent observation is needed? Dense triggers?

[wthrowe]

Yes.

[AlexCarpenter46]

Okay, changed the comments in the yamls to suggest dense output, let me know if this works @wthrowe

[wthrowe]

Yes, that's fine.

[knelli2]

Ignoring unrelated test timeouts/failures