Feature/MultiMode #295
Feature/MultiMode #295
Conversation
…alize mode in a few more places
There was a problem hiding this comment.
These are exciting updates, thank you! I have added a few comments. Mainly I am wondering if we should replace the existing functions with your multimode upgrade, since it is more general. (e.g. replace fFilterComplex with fFilterComplexArray.) I can help with this too. Will follow up offline for more thoughts. Thanks again!
| if(bTE==1) term1 = fFieldCore->GetBesselNKPrimeZeros(l,m) / GetDimR(); | ||
| else term1 = fFieldCore->GetBesselNKZeros(l,m) / GetDimR(); |
There was a problem hiding this comment.
can we add the full {} syntax for the if () {} else {} ? (The shorthand notation here has been a gotcha for me in the past.)
| if(bTE==1)lambda_c = 2 * LMCConst::Pi() * GetDimR() / fFieldCore->GetBesselNKPrimeZeros(l,m); | ||
| else lambda_c = 2 * LMCConst::Pi() * GetDimR() / fFieldCore->GetBesselNKZeros(l,m); |
There was a problem hiding this comment.
can we add the full {} syntax for the if () {} else {} ?
| int fTFNBins; | ||
| int fFIRNBins; | ||
| int fCropIndex; | ||
| std::vector < std::vector < std::vector < std::vector < int >>>> fFIRNBinsArray; |
There was a problem hiding this comment.
is fFIRNBins allowed to be different for each mode lmn? if not, I am wondering if we could use fFIRNBins to replace fFIRNBinsArray.
| double fResolution; | ||
| std::vector < std::vector < std::vector < std::vector < double >>>> fResolutionArray; |
There was a problem hiding this comment.
is fResolution allowed to be different for each mode lmn? if not, I am wondering if we could use fResolution to replace fResolutionArray.
| double fCharacteristicImpedance; | ||
| int fNSkips; | ||
| bool fHFSSFiletype; | ||
| ComplexFFT fComplexFFT; | ||
| bool fIsFIRCreated; | ||
| std::vector < std::vector < std::vector < std::vector < bool >>>> fIsFIRCreatedArray; |
There was a problem hiding this comment.
is fIsFIRCreated allowed to be different for each mode lmn? if not, I am wondering if we could use fIsFIRCreated to replace fFIRCreatedArray.
| protected: | ||
|
|
||
| // Member variables | ||
| std::string fHFSSFilename; | ||
| std::vector<double> fFilter; | ||
| fftw_complex* fFilterComplex; | ||
| std::vector< std::vector< std::vector < std::vector< fftw_complex*>>>> fFilterComplexArray; |
There was a problem hiding this comment.
This is where I am wondering if we could possibly just upgrade to your fFilterComplexArray, and delete references to the existing fFilterComplex.
| @@ -97,7 +113,7 @@ namespace locust | |||
| virtual bool Configure( const scarab::param_node& aNode) override; | |||
| bool ReadHFSSFile() override; | |||
| bool ConvertAnalyticTFtoFIR(double initialFreq, std::vector<std::complex<double>> tfArray); | |||
| bool ConvertAnalyticGFtoFIR(std::vector<std::pair<double,std::pair<double,double> > > gfArray); | |||
| bool ConvertAnalyticGFtoFIR(int bTE, int l, int m, int n, std::vector<std::pair<double,std::pair<double,double> > > gfArray); | |||
There was a problem hiding this comment.
similar to the above, can we just upgrade to your new implementation, and remove the old implementation altogether?
| /* | ||
| double CylindricalCavity::TotalFieldNorm(std::vector<double> field) | ||
| { | ||
| double norm = 0; | ||
| auto it = field.begin(); | ||
| while (it != field.end()) | ||
| { | ||
| if (!isnan(*it)) norm += (*it)*(*it); |
There was a problem hiding this comment.
is TotalFieldNorm not needed any more?
Source/Fields/LMCField.hh
Outdated
| virtual std::vector<double> GetNormalizedModeField(int l, int m, int n, std::vector<double> tKassParticleXP, bool includeOtherPols, bool teMode) {return {0.};}; | ||
| double NormalizedEFieldMag(std::vector<double> field); | ||
| virtual std::vector<std::vector<std::vector<double>>> CalculateNormFactors(int nModes, bool bTE) {return {{{0.}}};}; | ||
| virtual std::vector<double> GetTE_E(int l, int m, int n, double r, double theta, double z, bool includeOtherPols) {return {0.};}; | ||
| virtual std::vector<double> GetTM_E(int l, int m, int n, double r, double theta, double z, bool includeOtherPols) {return {0.};}; | ||
| virtual double CalculateDotProductFactor(int l, int m, int n, std::vector<double> tKassParticleXP, std::vector<double> aTE_E_normalized, double tThisEventNSamples) {return {0.};}; | ||
| virtual double CalculateDotProductFactor(int bTE, int l, int m, int n, std::vector<double> tKassParticleXP, std::vector<double> aTE_E_normalized, double tThisEventNSamples) {return {0.};}; |
There was a problem hiding this comment.
is the bTE required for the dot product calculation, given that the E-field and e- velocity are inputs? lmk your thoughts.
|
Expansion of MultiMode features to a broader range of parameters, such as DHO Threshold and frequency (usually not needed, but may be needed if we ever look at higher harmonics). Also generalized configurable parameters beyond just TE011 and TM111 modes |
…rencing mode indices.
…transmitter needs to be aligned with multimode syntax and then retested.
…to address mode selection
…eturns a vector of modes, instead of a boolean.
…or rearrangement to configuration since fModeSet is now extracted from LMCField.
multimode testing
…se to quadrants 1 and 4 in complex plane, instead of 1->4. This will likely need to be discussed/checked when lab data become available.
Updates DHO model to accommodate independent configurations for different modes