Cheers,

Ehsan.

Statistics: Posted by ehsan — Mon Feb 08, 2016 3:28 am

]]>

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

Statistics: Posted by rhtownsend — Sun Feb 07, 2016 2:54 pm

]]>

Let's focus on the user-supplied

Code:

`n_freq`

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.

Statistics: Posted by ehsan — Sun Feb 07, 2016 9:37 am

]]>

If narf_approx = .TRUE., GYRE uses the non-adiabatic radial flux (NARF) approximation, as discussed in Townsend (2005, MNRAS, 360, 465). Otherwise, GYRE uses the same approach as described in Bouabid et al. (2013, MNRAS, 429, 2500).

cheers,

Rich

Statistics: Posted by rhtownsend — Fri Feb 05, 2016 3:50 pm

]]>

Kind regards,

Ehsan.

Statistics: Posted by ehsan — Fri Feb 05, 2016 10:47 am

]]>

fffeynman wrote:

Hi, Rich

Is it possible to add the coefficients of Hough function as a combination of spherical harmonics

to the mode or summary file? It is interesting to use them to calculate mode visibility for g modes.

Thanks!

best regards,

Zhao

Hi, Rich

Is it possible to add the coefficients of Hough function as a combination of spherical harmonics

to the mode or summary file? It is interesting to use them to calculate mode visibility for g modes.

Thanks!

best regards,

Zhao

Hi Zhao --

GYRE doesn't have direct access to the coefficients, as it only needs the Hough eigenvalues (lambda) to solve the pulsation equations within the traditional approximation (and it uses pre-calculated tables to evaluate these eigenvalues).

However, it should be relatively straightforward to write a wrapper around the astro_hough module (see src/extern/astro/astro_hough.fpp) which does what you want. Feel free to email me if you would like some help with this.

Best wishes,

Rich

Statistics: Posted by rhtownsend — Mon Jan 25, 2016 9:03 am

]]>

Yes, this is something I can add to the next release.

cheers,

Rich

Statistics: Posted by rhtownsend — Sat Jan 23, 2016 10:26 pm

]]>

Best regards

Ehsan.

Statistics: Posted by ehsan — Wed Jan 20, 2016 2:09 pm

]]>

to the mode or summary file? It is interesting to use them to calculate mode visibility for g modes.

Thanks!

best regards,

Zhao

Statistics: Posted by fffeynman — Tue Jan 19, 2016 3:59 pm

]]>

Thanks anyway.

Ehsan.

Statistics: Posted by ehsan — Fri Dec 11, 2015 11:28 am

]]>

This allows handling the output for the same degree, but different azimuthal degrees much simpler.

Then, the AWESOME GYRE will become AWESOMER.

Best regards

Ehsan.

Statistics: Posted by ehsan — Fri Dec 11, 2015 11:05 am

]]>

New features since release 4.2 include:

- Added the COLLOC_GL6 IVP solver
- Allowed usage of COLLOC_GL4 and COLLOC_GL6 IVP solvers for non-adiabatic calculations. These give much better results than the corresponding MAGNUS_GL4 and MAGNUS_GL6 solvers
- Set COLLOC_GL2 as the default IVP solver
- Added narf_approx flag to &osc namelist; set to .TRUE. to turn on the non-adiabatic radial flux (NARF) approximation
- Added x_i and x_o parameters to &scan_grid and &recon_grid namelists, to allow the specification of the inner- and outermost grid points
- Changed the assumed time dependence of oscillations to exp(-i omega t). This means that modes with positive Im(omega) are unstable, and vice versa -- the opposite of the behavior in previous versions of GYRE
- Changed the m output item to mean the azimuthal order; the interior mass is now accessed through the M_r item

The addition of the COLLOC_GL4 and COLLOC_GL6 solvers is a big step forward; they are faster yet more stable than the Magnus solvers, and should generally be preferred for all calculations. The COLLOC_GL4 solver probably gives the best compromise between accuracy and speed.

As usual, the source code can be downloaded from

https://bitbucket.org/rhdtownsend/gyre/downloads/

Rich

Statistics: Posted by rhtownsend — Thu Sep 17, 2015 10:14 am

]]>

The restriction of gyre_nad to MAGNUS_GL2 is certainly annoying. The next release of GYRE will hopefully include a new set of solvers, which allow non-adiabatic calculations at 2nd, 4th and 6th-order accuracy. Watch this space!

Statistics: Posted by rhtownsend — Thu Jul 16, 2015 4:27 am

]]>

Sorry for spamming the forum.

Best

Ehsan.

Statistics: Posted by ehsan — Wed Jul 15, 2015 4:57 pm

]]>

I have prepared a tarball with the inlist and the input model; however, I cannot attach the file because it is claimed too large! It is actually 388 Kb! I am going to email you the input file.

Thanks for your consideration.

Ehsan.

Statistics: Posted by ehsan — Wed Jul 15, 2015 3:46 pm

]]>