Refactored DirectivityData to store far fields and flux as fields, and compute radiation parameters via properties

[QimingFlex]

No description provided.

[momchil-flex]

Does it make more sense to store the linearly polarized fields and add properties to get the circularly polarized ones?

[QimingFlex]

Does it make more sense to store the linearly polarized fields and add properties to get the circularly polarized ones?

Linearly polarized fields are the regular far-field components Etheta​ and Ephi​. I was previously thinking of putting E_left and E_right as properties of FarfieldProjectionMonitor, but doing so would require users to define both FarfieldProjectionMonitor and DirectivityMonitor to obtain all radiation characteristics. So I placed E_left​ and E_right​ under DirectivityMonitor, allowing users to access these radiation characteristics with just one monitor. Maybe a better way is to keep all six far-field components (Er to Hphi​) as fields in DirectivityData and introduce E_left​ and E_right as properties?

[dmarek-flex]

Does it make more sense to store the linearly polarized fields and add properties to get the circularly polarized ones?

I agree. For simplicity and extensibility, I think the DirectivityData should only store Etheta/Ephi far fields and total flux. Most antenna characteristics of interest can be derived from that data. We should not even need the radial components in the far field. (We could also compute H far fields on-the-fly given the background medium, but maybe simpler to keep it the way it is and store it explicitly.)

@QimingFlex can you think of any parameters of interest where the far field approximation is not used for antennas?

[QimingFlex]

Does it make more sense to store the linearly polarized fields and add properties to get the circularly polarized ones?

I agree. For simplicity and extensibility, I think the DirectivityData should only store Etheta/Ephi far fields and total flux. Most antenna characteristics of interest can be derived from that data. We should not even need the radial components in the far field. (We could also compute H far fields on-the-fly given the background medium, but maybe simpler to keep it the way it is and store it explicitly.)

@QimingFlex can you think of any parameters of interest where the far field approximation is not used for antennas?

This sounds like a good plan. We store DirectivityData only with Etheta/Ephi, Htheta/Hphi, and total flux. Other characteristics, such as directivity, axial ratio, and polarized fields, are defined as properties. How do you think? @weiliangjin2021

[weiliangjin2021]

This sounds like a good plan. We store DirectivityData only with Etheta/Ephi, Htheta/Hphi, and total flux. Other characteristics, such as directivity, axial ratio, and polarized fields, are defined as properties. How do you think?

Sounds good to me.

[momchil-flex]

Sorry, wouldn't this now be almost identical to a far field monitor? Should we consider unifying, e.g. deprectating DirectivityMonitor, and adding the directivity, axial ratio, etc. properties to the FarFieldAngleMonitor?

[QimingFlex]

Sorry, wouldn't this now be almost identical to a far field monitor? Should we consider unifying, e.g. deprectating DirectivityMonitor, and adding the directivity, axial ratio, etc. properties to the FarFieldAngleMonitor?

The difference lies in DirectivityMonitor inheriting FluxMonitor to compute directivity. Do you think it would be better for FarFieldAngleMonitor to inherit FluxMonitor and store flux as a field in FarFieldAngleData? This will allow DirectivitiMonitor to be depracted.

[momchil-flex]

Ok, I think it makes sense as is.

Note that you're modifying the notebooks submodule.

[dmarek-flex]

Great, this looks a lot simpler @QimingFlex! Couple of simple things and yea just need to revert the notebooks module.

[weiliangjin2021]

Could you also add tests for left and right polarization?

[weiliangjin2021]

Approve once tests for right/left polarization have been added