The GYRE Forums

Hello.
I think a very accommodating feature to add - on the wish list - is to have a capability to scan over a range of ell, all set up in the inlist.
This comes very handy when one tries to run GYRE over a large number of input files, as is my case now.
Then, the same inlist would take care of the whole ell scanning.

The other wish is to have a flexibility for the on-screen output. E.g. i do not understand the whole output lines starting with "Eval ...".
It would be nice to have a control over this.

And the last (but not the least), is to have a criteria to let GYRE stop the frequency search if the mode order in p- or g-mode regime exceeds a pre-defined threshold; a ceiling for p-modes and a floor for g-modes.
For instance, I do not like to go beyond p5, even if the assigned frequency scan interval allows.
This nearly translates to an alternative scanning strategy in terms of mode order rather than the frequency, which may overcome the issue of very closely packed g-modes in dense stellar models, where a little difference in frequency would lead to large difference in n_g.

How do these seem?

Kind regards
Ehsan.

ehsan wrote:Hello.
I think a very accommodating feature to add - on the wish list - is to have a capability to scan over a range of ell, all set up in the inlist.
This comes very handy when one tries to run GYRE over a large number of input files, as is my case now.
Then, the same inlist would take care of the whole ell scanning.

The other wish is to have a flexibility for the on-screen output. E.g. i do not understand the whole output lines starting with "Eval ...".
It would be nice to have a control over this.

And the last (but not the least), is to have a criteria to let GYRE stop the frequency search if the mode order in p- or g-mode regime exceeds a pre-defined threshold; a ceiling for p-modes and a floor for g-modes.
For instance, I do not like to go beyond p5, even if the assigned frequency scan interval allows.
This nearly translates to an alternative scanning strategy in terms of mode order rather than the frequency, which may overcome the issue of very closely packed g-modes in dense stellar models, where a little difference in frequency would lead to large difference in n_g.

How do these seem?

Kind regards
Ehsan.

Thanks for the suggestions, Ehsan. Running with multiple values of l in a single input file is now implemented in v2.0 of GYRE; let me know how it works for you.

The screen output has also been tidied up somewhat in v2.0; the columns are now labeled, for instance. The 'Eval' lines printed out (which, incidentally, only appear when GYRE is compiled with debugging enabled) indicate the value of the discriminant function D(omega) at each value of omega in the frequency scan.

I hear your point about having control over the screen output, but this is lower on my priority list because the screen output is just meant to indicate the progress of the run. The actual results from the run should be taken from the summary and mode files, which are user-configurable.

Finally, the option to scan over a range of radial orders is a very interesting one, and I will look into implementing this.

Many thanks again,

Rich

Hello Rich and thanks for your comment.
I have tested the scanning over multiple ell, and have always succeeded.
I also admit enjoying to follow the on-screen output with version 2.0, as the column names are clear now.
I know that assigning mode order is a non-trivial problem, and I look forward into its implementation.
Based on my current limited experience with GYRE, there occurs cases that a p-mode appears between the list of g-modes. I did not report this on the forum.
But, it happened with an RGB model, and I had my shooting and reconstruction grids set to 'RESAMP_DISPERSION', and the g-mode order was monotonically increasing.
With many changes to the inlist, I am not sure I can reproduce that on-screen output anymore, but will give you the feedback if it occurs again.

Regards.
Ehsan.