We may want to think of having an overrarching "MagneticDiagnostic" objective that tries to minimize the re-computation of the magnetic field (think, concatenate all of the eval coords for both point B measurements for B probes, as well as the points along the curves for flux/mirnov and partial/full rogowski loops, to better take advantage of vectorization.

Something I would sort of like is to have some sort of wrapper MagneticDiagnostic around the sub-diagnostic objectives, whose only job is to

• take in the source resolutions for the external field and the plasma-generated field
• receive from the sub-objectives what evaluation coordinates in real space they require
• concatenate these coordinates together into a single (n, 3) array (while keeping track of which parts are needed by which sub-objective)
• compute the plasma-generated magnetic field and the external magnetic field at these points
• send the necessary info for each sub-diagnostic so it can compute its own error
• maybe with the ._compute(params, field) method outlined below
• concatenate these errors and return as one single array
  • (may be though annoying if

I think that maybe one potential way could be for reconstruction objectives to have two compute functions,

• one which is the usual objective.compute and takes in params only (and constants until after Remove constants from _Objective #1758 )
• another which takes in the params needed for this as well as the total magnetic field evaluated at the physical coordinates it needs, and it then uses this already-computed field to do whatever integrations it needs. something like just ._compute(params, field)
  • This may be need some extra logic with the current idea I have for FluxLoop , which takes in an entire coilset of the individual mirnov/flux loop diagnostics, as we need to take the coords of each coil and flatten them to send to the MagneticDiagnostic class, then when it receives the coords it will have to reshape them and re-split them up according to the individual loops.

(may be kind of annoying though as if say you included a rogowski loop and a point B measurement, if we allowed diagnostic positions (like rog coil shape) to change, we would have to track within this objective which params go to where. Not a big issue if diagnostics are assumed fixed though)

Something that should be checked with all this is if it is worth it, that is, it is not like these are singular integrals, the only thing this would do is ensure that the maximum vectorization possible is being carried out (i.e. the largest single array eval_coords is being computed). However I think for Bplasma computations, the sources will either be 2D surface currents (in case of using virtual casing principle) or 3D volume currents (in case of #996 ), both of which quickly require large amounts of memory for even modest numbers of eval points.