You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For certain applications, it may be useful to compute the driven frequency domain response for a complex-valued frequency omega = omega_R + i omega_I. Currently the "Driven" problem type only supports a real-valued frequency range, configured by the parameters "MinFreq", "MaxFreq", and "FreqStep". We could add a parameter to specify the maximum imaginary part of the frequency, or could allow "MinFreq" and "MaxFreq" to be complex-valued numbers specifying the lower-left and upper-right corners of a rectangular contour in the complex plane, with parameters for the number of frequency samples to use per side.
Internally, the "Driven" problem type already considers a complex-valued system matrix and so there just need to be changes to the code to handle the case where the given omega is complex. This is already done for the (experimental) FEAST eigenvalue solver and so can be extended throughout the code base to handle this more general condition. Likewise the adaptive fast frequency sweep will need to train the PROM on the frequency contour in the complex plane rather than real-valued frequency interval. We will still use a real-valued preconditioner matrix constructed using the coefficient |omega|, so nothing should need to change there.
For certain applications, it may be useful to compute the driven frequency domain response for a complex-valued frequency
omega = omega_R + i omega_I
. Currently the"Driven"
problem type only supports a real-valued frequency range, configured by the parameters"MinFreq"
,"MaxFreq"
, and"FreqStep"
. We could add a parameter to specify the maximum imaginary part of the frequency, or could allow"MinFreq"
and"MaxFreq"
to be complex-valued numbers specifying the lower-left and upper-right corners of a rectangular contour in the complex plane, with parameters for the number of frequency samples to use per side.Internally, the
"Driven"
problem type already considers a complex-valued system matrix and so there just need to be changes to the code to handle the case where the givenomega
is complex. This is already done for the (experimental) FEAST eigenvalue solver and so can be extended throughout the code base to handle this more general condition. Likewise the adaptive fast frequency sweep will need to train the PROM on the frequency contour in the complex plane rather than real-valued frequency interval. We will still use a real-valued preconditioner matrix constructed using the coefficient|omega|
, so nothing should need to change there.@phdum
The text was updated successfully, but these errors were encountered: