strange behavior of l=1 ridge for Procyon

[mjoyce]

Hey again,

I've still not resolved the Procyon-DSEP mess, but I have now tried to model 16 Cyg A & B seismically as well. Despite healthy-looking structural output (thanks Warrick for tomso), we are still getting diagrams that look like this (attached-- 16 Cyg B).

16CygB.png (80.91 KiB) Viewed 4390 times

The ridges are out of order, consistently, for every model in my grid. I also note that without reordering the data using Warrick's tool, the non-monotonic abscissa issue pops up.

I've attached the gonge file and frequency output.
Tim points out that the n_pg values don't make sense given n_p and n_g in the frequency output.

Any ideas?

[mjoyce]

also, model file:

[warrick]

Despite healthy-looking structural output (thanks Warrick for tomso), ...

Not sure the structure is that healthy! The model you sent also has a nasty Gamma_1 jump at T=1e6 K:

Screenshot from 2019-11-29 10-09-39.png (27.59 KiB) Viewed 4387 times

The ridges are out of order, consistently, for every model in my grid. I also note that without reordering the data using Warrick's tool, the non-monotonic abscissa issue pops up.

I was going to say that this needs to be fixed in DSEP when it writes out the file but then I had another look at the FGONG specification and realised that the order of points in an FGONG file is never specified. So center-to-surface is also valid FGONG but GYRE currently expects the order to be surface-to-center. Unless Rich picks it up first, I'll try to write a patch that will test the ordering of the radial co-ordinate to decide whether or not it needs to be reversed.

Cheers,
Warrick

[warrick]

Unless Rich picks it up first, I'll try to write a patch that will test the ordering of the radial co-ordinate to decide whether or not it needs to be reversed.

I've opened a one-line pull request to fix the one offending line of code but you can change it yourself in the release version and rebuild GYRE. The fix is to change line 130 of $GYRE_DIR/src/model/gyre_fgong_file.fpp from

Code: Select all

    var = var(:,n:1:-1)

to

Code: Select all

    if (ALL(var(1,2:) <= var(1,:SIZE(var, dim=2)))) var = var(:,n:1:-1)

I checked that I get the same mode frequencies as when I reverse the order of the model using tomso and GYRE's tests still pass. If any gotchas come out of the pull request I'll try to remember to cross-post it here too.

W

[mjoyce]

Despite healthy-looking structural output (thanks Warrick for tomso), ...

Not sure the structure is that healthy! The model you sent also has a nasty Gamma_1 jump at T=1e6 K:
Screenshot from 2019-11-29 10-09-39.png

The ridges are out of order, consistently, for every model in my grid. I also note that without reordering the data using Warrick's tool, the non-monotonic abscissa issue pops up.

I was going to say that this needs to be fixed in DSEP when it writes out the file but then I had another look at the FGONG specification and realised that the order of points in an FGONG file is never specified. So center-to-surface is also valid FGONG but GYRE currently expects the order to be surface-to-center. Unless Rich picks it up first, I'll try to write a patch that will test the ordering of the radial co-ordinate to decide whether or not it needs to be reversed.

Cheers,
Warrick

Indeed that is not at all healthy... I generated this exact plot for *something* and did not see a discontinuity, but evidently not this. I must have attached a different file from the one I looked at; sorry about that

Thanks for the patch! I will try it.

I have no doubt that most of the issue lies with DSEP, but I do note that there are clear differences in effectiveness between GYRE 4.4 and GYRE 5+ when it comes to this modeling point specifically. I do not know why. Was there some point at which the organization/handling of fgong files changed significantly in GYRE, and would this be documented somewhere?

[warrick]

I have no doubt that most of the issue lies with DSEP, but I do note that there are clear differences in effectiveness between GYRE 4.4 and GYRE 5+ when it comes to this modeling point specifically. I do not know why. Was there some point at which the organization/handling of fgong files changed significantly in GYRE, and would this be documented somewhere?

That's interesting. I won't have a chance to look at this again until Thursday but I'll try different versions of GYRE between 4.4 and 5.2 and see if I can find what changed.

[rhtownsend]

I have no doubt that most of the issue lies with DSEP, but I do note that there are clear differences in effectiveness between GYRE 4.4 and GYRE 5+ when it comes to this modeling point specifically. I do not know why. Was there some point at which the organization/handling of fgong files changed significantly in GYRE, and would this be documented somewhere?

That's interesting. I won't have a chance to look at this again until Thursday but I'll try different versions of GYRE between 4.4 and 5.2 and see if I can find what changed.

My recollection is that I changed a lot of the gridding code was rewritten, to properly handle discontinuities. This may have fixed some bugs lurking in 4.4, and introduced new ones. Worth checking out the release notes here:

https://github.com/rhdtownsend/gyre/releases

cheers,

Rich