search

sxs-collaboration / spectre

SpECTRE is a code for multi-scale, multi-physics problems in astrophysics and gravitational physics.
https://spectre-code.org
Other
158 stars 187 forks source link

Control systems ignore measurements #3964

Open wthrowe opened 2 years ago

wthrowe commented 2 years ago

Discussion copied from #3883:

      // Check if we actually need to use the measurement. If a control system
      // is on a longer timescale, we don't need to store frequent measurements

@wthrowe:

@markscheel is this right? I thought you said frequent measurements were always better.

@knelli2:

Frequent measurements are needed for maps that are changing quickly, like size. However, expansion (and the other basic control systems) only stores the most recent 2 or 3 measurements in order to calculate the derivatives of the control error (see Averager.cpp). Thus, if expansion had super frequent measurements between updates t1 and t2, it'd only keep the 3 most recent measurements closest to t2 and there'd be no info from the beginning of the interval. The reason this is bad is because those measurements (specifically for expansion, the centers of the horizons) can be a bit noisy between horizon finds so the center won't be a very smooth function if you look measurement by measurement. So if we only use 3 noisy measurements from the end of the interval, this can mess up the calculation of the control error.

This line helps spread out which measurements a control system chooses to use so that it has approx evenly spaced measurements between t1 and t2, reducing the noise from frequently changing horizon centers.

@wthrowe:

That seems reasonable, but @markscheel can you verify this?

@markscheel:

I would think that frequent measurements (i.e. using more measurements to compute derivatives and to average over) would always make things better, because more of the noise would be averaged away. But that assumes that we are using (i.e. averaging over) many measurements.

If we are instead making a large number of measurements but throwing away most of them, and using only 2 or 3 measurements per update in the Averager, then it makes sense to me to choose those measurements to be spread out over time. Spreading them out would not only reduce the noise, but also it would better sample the function, which presumably is changing only over a long time scale (or else you would be making more frequent updates).

Presumably the reason to use only 2 or 3 measurements is to save memory? This is probably significant only for the Shape map, where each measurement effectively stores an entire Strahlkorper, whereas each measurement of rotation/expansion/translation stores just a few doubles. But even a bunch of Strahlkorpers on a singleton might not be so bad.

Another reason to use only 2 or 3 measurements might be to better copy what SpEC does. SpEC doesn't explicitly throw away measurements, but the fast (size) and slow (everything else) control systems in SpEC are triggered separately, so the slow control systems never see the AH measurements that are done for the fast control systems. So the end result is the same as throwing measurements away. The 2 or 3 measurements per update done in SpEC was chosen because that is the minimum number of measurements you can get away with for the control system to be stable. Using 5 or 6 instead of 2 or 3 should make things less noisy, but more measurements means more AH finds, which means more CPU time.

But in SpECTRE, doing more measurements is free [except maybe for memory], because the 'fast' control systems already do those measurements, so it may be worth departing from what SpEC does and measure more frequently (as long as all those measurements are used).

And another thing to think about: in SpEC, all the 'slow' control systems are measured and updated simultaneously, even if they have different intrinsic timescales. The measurement frequency and update frequency are determined by the fastest of the 'slow' control systems. This means if (for example) expansion turned out to have a 2 orders of magnitude longer timescale than rotation, then expansion is being measured and updated two orders of magnitude more frequently than it needs to be. So it may be better in this case to update expansion less often but still measure expansion at the same frequency, so expansion would then have more measurements per update and therefore more averaging. But we haven't tried this approach in SpEC.

@wthrowe:

Lots to think about there. I'm not sure I've absorbed all of it, but I have an initial thought:

I don't think we want to use the same measurement for the fast and slow control systems, because the fast systems are single-hole. If you use the measurement of both holes and the two holes have different timescales (I assume they roughly scale with the mass), you're forcing a bunch of horizon finds on the slower of the two that will either only be used as one of many points in an averager or will be thrown away entirely.

Has that plan changed, or is this just about the differences in the timescales for the different slow systems?

@markscheel:

Good point. Not sure about how we should separate fast vs slow. If we have different triggers for fast and slow, and some of the triggers happen to coincide, does that mean that we do extra AH finds? That would be the only potential downside of separating the triggers for fast vs slow.

On a related note, Kyle and I realized yesterday that even if there are only slow control systems, SpECTRE measurements work different than SpEC. Here's an example. Suppose there are only two slow control systems (call them A and B) and suppose A has an intrinsic timescale of 120, and B has an intrinsic timescale of 60. Then the maximum update interval for A is 40, and the maximum update interval for B is 20. And also therefore the maximum measurement interval for A is 10, and the maximum measurement interval for B is 5. (This is for our usual choice of parameters: timescale = 3t_update = 12t_measurement, which is necessary for stability of the control system).

In this current SpECTRE implementation, B is measured every delta_t = 5 and updated every delta_t = 20, but A is measured every delta_t = 10 (it skips every other measurement) and A is updated every delta_t = 40. In SpEC, what happens is that BOTH A and B are measured every delta_t = 5 and updated every delta_t = 20.

Kyle told me yesterday he would think about how the algorithm would change if we wanted to keep the updating intervals the same as in SpEC.

Edit: Missed a comment in the thread.

wthrowe commented 2 years ago

@markscheel, can you give an example where everything isn't different by factors of two? It's not clear to me which things are happening because they want to happen then vs. because it is twice the other time.