GYRE inlist without n_freq

Suggestions for improvements, new features, etc.
Post Reply
ehsan
Posts: 88
Joined: Sun Jun 16, 2013 11:31 am

GYRE inlist without n_freq

Post by ehsan » Sun Feb 07, 2016 9:37 am

Dear Rich,
I was just giving the GYRE runtime efficiency a quick thought, and would like to share a very raw idea.
Let's focus on the user-supplied

Code: Select all

n_freq
in the GYRE inlist.

The most efficient way to scan for all roots of the S(omega) determinant within the pre-defined frequency scan range, say from f_a to f_b, is to compute at least N trial frequencies, f_i between f_a and f_b. So, if the n_freq in the inlist would be less than N (the total number of roots in this frequency range), some modes will be missed/skipped, in either the linear or inverse scheme. If one specifies n_freq > N, then exactly N discrete set of modes will be found, and the life is happy. However, if a user specifies n_freq >> N, nothing new is going to be resolved, and that is an immense loss of resources (and computation time). So, why not get rid of n_freq, if possible?

I "speculate" you can very simply optimise it.
if one solves S(omega) twice, one for the lower frequency and one for the upper frequency, and subtract their corresponding radial order (n = |n_p| + |n_g|), then one can expect the range of radial orders between the two modes closest to f_a and f_b. Consequently, the difference between the two radial orders of the two-end modes "could" gives an accurate estimate of the expected number of roots of S(omega), hence, N. Thus, n_freq can be internally estimated, and set, instead of externally defined.
For the sake of conservation, n_freq can be set by e.g. 10% larger than N.

I "imagine" this would straightforwardly work for pure p- and/or g-modes. This may get a bit nasty for mixed modes, and specially when rotation is included (since higher-order g-modes get too packed with decreasing frequency), but a straightforward scheme may also be found.

Very raw idea, but just liked to share it with you. For some practical reason that I'm unaware of, it may even not work.
Let me know please what you think.

Ehsan.

User avatar
rhtownsend
Site Admin
Posts: 397
Joined: Sun Mar 31, 2013 4:22 pm

Re: GYRE inlist without n_freq

Post by rhtownsend » Sun Feb 07, 2016 2:54 pm

Hi Ehsan --

This is a very good suggestion, and one that I have considered implementing for some time now. Since it relies on mode identifications to figure out how many modes are in a given interval, my recent focus with GYRE has been getting the mode id's correct -- and in turn, this requires proper handling of density discontinuities.

I'm currently readinying GYRE 5.0 for release -- this includes the density-discontinuity code. With that done, I'll be working on adaptive frequency searching, such as you describe above.

cheers,

Rich

ehsan
Posts: 88
Joined: Sun Jun 16, 2013 11:31 am

Re: GYRE inlist without n_freq

Post by ehsan » Mon Feb 08, 2016 3:28 am

Can't wait to fetch the brand new version 5.0.

Cheers,
Ehsan.

Post Reply