Thank you very much for the help - I definitely didn't pick up that those were functors, but reading up on them they seem very useful especially for what I want to do.

If you don't mind me asking, do you have any tips for using this library in a real-time application? I want to use it for aircraft system simulation in a home flight sim, and my plan is to model the more timestep-sensitive components as a system of DAEs, whereas other components will just use Euler integration. I'll pass around the inputs and outputs as necessary once per loop of the flight model (aiming for at least ~60hz). Each system of DAEs would include <20 variables/equations. Does this sound like a reasonable approach?

That sounds like a very interesting project!

Solving the system of about 20 equations at approximately 60Hz is certainly feasible. To prove the point, I just took one of the existing examples (perovskite.cpp, which solves a large system of DAEs) and set the number of equations to 40. From the output (in verbose mode), the solver made 21 time steps, and it took about a millisecond to do the job, including initialisation and printing:

Starting dae-cpp version 2.2.0...
Float size:      64 bit
Integer size:    32 bit
BDF max order:   4
Newton scheme:   1
Max time step:   1e+10
DAE system size: 40 equations
Calculating...

-- Integration time t = 10:
Step 1        :: t = 0.01        :: BDF-1: dt=0.01        :: #*#>
Step 2        :: t = 0.03        :: BDF-2: dt=0.02        :: #*#>
Step 3        :: t = 0.07        :: BDF-3: dt=0.04        :: #*#>
Step 4        :: t = 0.15        :: BDF-4: dt=0.08        :: #*#*>
Step 5        :: t = 0.31        :: BDF-4: dt=0.16        :: #*#*>
Step 6        :: t = 0.63        :: BDF-4: dt=0.32        :: #*#*>
Step 7        :: t = 1.27        :: BDF-4: dt=0.64        :: #*#*#
Step 8        :: t = 1.91        :: BDF-4: dt=0.64        :: #*#*#
Step 9        :: t = 2.55        :: BDF-4: dt=0.64        :: #*#*#
Step 10       :: t = 3.19        :: BDF-4: dt=0.64        :: #*#*#
Step 11       :: t = 3.83        :: BDF-4: dt=0.64        :: #*#*#
Step 12       :: t = 4.47        :: BDF-4: dt=0.64        :: #*#*#
Step 13       :: t = 5.11        :: BDF-4: dt=0.64        :: #*#*#
Step 14       :: t = 5.75        :: BDF-4: dt=0.64        :: #*#*#
Step 15       :: t = 6.39        :: BDF-4: dt=0.64        :: #*#*#
Step 16       :: t = 7.03        :: BDF-4: dt=0.64        :: #*#*#
Step 17       :: t = 7.67        :: BDF-4: dt=0.64        :: #*#*#
Step 18       :: t = 8.31        :: BDF-4: dt=0.64        :: #*#*#
Step 19       :: t = 8.95        :: BDF-4: dt=0.64        :: #*#*#
Step 20       :: t = 9.59        :: BDF-4: dt=0.64        :: #*#*#
Step 21       :: t = 10          :: BDF-4: dt=0.41        :: #*#*>
...done

Computation time:
----------------------------------------------------------------
  Initialization:             0.072 ms  (6.47%)
  Time derivative:                0 ms  (0%)
  RHS:                            0 ms  (0%)
  Mass matrix:                0.001 ms  (0.089%)
  Jacobian matrix:            0.058 ms  (5.21%)
  Linear algebra:             0.006 ms  (0.539%)
  Matrix factorization:       0.535 ms  (48.1%)  <--  56 calls
  Linear solver:              0.001 ms  (0.089%)  <--  95 calls
  Error control:                  0 ms  (0%)
  Solution Manager:           0.001 ms  (0.089%)
  Other calculations:         0.439 ms  (39.4%)
----------------------------------------------------------------
Total time:                   1.113 ms  (100%)
----------------------------------------------------------------

So theoretically, it can solve the system at around 1000Hz frequency, which is well faster than 60Hz.
This of course will depend on the number of time steps and the Jacobian matrix sparsity (i.e., how tightly the equations are coupled).

Using

opt.solution_variability_control = false; // Switches off solution variability control for better performance
opt.Newton_scheme = 2; // Quasi-Newton method II (balanced with focus on speed, updates Jacobian and performs factorization every 3rd iteration)

can further increase performance.

You can also play with the initial time step opt.dt_init (which is 0.01 by default) and try different Newton schemes defined by opt.Newton_scheme.

Finally, if you run the DAE solver multiple times in a loop, there might be significant overhead related to the solver initialisation (memory allocations) and other calculations, which might not be necessary to do every time.
To determine performance bottlenecks, you can set up your DAE system, run the solver in a loop (which mimics your application's main loop), and do code profiling. It will show you how much time is spent in different parts of the code (including the solver). I've been using gperftools as a profiler, but it might be outdated by modern standards, and you may want to look up more popular and flexible solutions.

Wow thank you so much for running through that, it’s really encouraging to see how quickly this runs. I’ll look into code profiling, that will definitely be useful to trial different approaches.

I now have the example dae working within the sim, so next steps will be to plug in one of my component models and see some real results. Thank you again for the help and guidance!