Add aux field monitors

[caseyflex]

Adds monitor class AuxFieldTimeMonitor and corresponding data classes AuxFieldTimeData and AuxFieldTimeDataset. Currently it is modeled after FieldTimeMonitor -- you specify some aux field components to download, and it puts those in the corresponding data class. The default is no aux field components. Any field components which don't correspond to nonlinearities which are present in the region / material / simulation are just stored as 0.

Todo:

• Add frontend unit tests
• Finalize api
• Maybe validate against requesting nonlinear aux field components for nonlinearities not present in the simulation. This was the purpose of the function _aux_fields in Simulation.

[yaugenst-flex]

Thanks @caseyflex this looks really solid so code-wise I don't have any comments, more of a general question - is this something that we expect users to use or is it mostly for internal purposes? Also, what would happen if we were to add support for more auxiliary fields in the future? I wonder if these fields could just be stored in the regular FieldTimeData?

[caseyflex]

Thanks @caseyflex this looks really solid so code-wise I don't have any comments, more of a general question - is this something that we expect users to use or is it mostly for internal purposes? Also, what would happen if we were to add support for more auxiliary fields in the future? I wonder if these fields could just be stored in the regular FieldTimeData?

Yeah, I think users will use it. Already knowing the free-carrier density when using TwoPhotonAbsorption nonlinearity is quite useful.

Regarding future aux fields -- I was thinking that we could just add more fields to AuxFieldTimeData every time we need to add a new field. Would that cause backwards compatibility issues? This is related to the last point of just using FieldTimeData -- in principle we could use that here too, but we would need to add fields to it which would clutter that dataset (currently it has Ex, Ey, Ez, Hx, Hy, Hz and nothing else). Also electromagnetic field data is treated specially in other places; you can compute poynting vectors, overlaps, and other things that don't make sense for aux fields.

[yaugenst-flex]

Regarding future aux fields -- I was thinking that we could just add more fields to AuxFieldTimeData every time we need to add a new field. Would that cause backwards compatibility issues?

No I think that'd be fine as long as all fields are optional.

Also electromagnetic field data is treated specially in other places; you can compute poynting vectors, overlaps, and other things that don't make sense for aux fields.

Yeah I agree. Let's keep it like this for now.

[momchil-flex]

I took another look at this PR to see if the symmetry expansion, and grid locations would be correctly handled and I'm pleasantly surprised that this seems to have been set up in a pretty expandable way previously! :D I was worried about it.