strange behavior of l=1 ridge for Procyon

General discussion of all things GYRE-related (e.g., results, talks, ideas, tips)
mjoyce
Posts: 10
Joined: Tue Oct 30, 2018 6:42 pm

Re: strange behavior of l=1 ridge for Procyon

Post by mjoyce » Fri Nov 29, 2019 1:54 am

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
16CygB.png (80.91 KiB) Viewed 256 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?
Attachments
freq_m108.2.16CygB.1.8500.Z0.0230.Y0.26.txt
(8.58 KiB) Downloaded 6 times
m108.2.16CygB.1.8500.Z0.0230.Y0.26_gonge.txt
(1.29 MiB) Downloaded 5 times

mjoyce
Posts: 10
Joined: Tue Oct 30, 2018 6:42 pm

Re: strange behavior of l=1 ridge for Procyon

Post by mjoyce » Fri Nov 29, 2019 2:31 am

also, model file:
Attachments
model.in
(1.79 KiB) Downloaded 5 times

warrick
Posts: 69
Joined: Wed Aug 28, 2013 2:47 am

Re: strange behavior of l=1 ridge for Procyon

Post by warrick » Fri Nov 29, 2019 5:25 am

mjoyce wrote:
Fri Nov 29, 2019 1:54 am
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
Screenshot from 2019-11-29 10-09-39.png (27.59 KiB) Viewed 253 times
mjoyce wrote:
Fri Nov 29, 2019 1:54 am
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
Posts: 69
Joined: Wed Aug 28, 2013 2:47 am

Re: strange behavior of l=1 ridge for Procyon

Post by warrick » Fri Nov 29, 2019 7:32 am

warrick wrote:
Fri Nov 29, 2019 5:25 am
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
Posts: 10
Joined: Tue Oct 30, 2018 6:42 pm

Re: strange behavior of l=1 ridge for Procyon

Post by mjoyce » Sun Dec 01, 2019 2:29 am

warrick wrote:
Fri Nov 29, 2019 5:25 am
mjoyce wrote:
Fri Nov 29, 2019 1:54 am
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
mjoyce wrote:
Fri Nov 29, 2019 1:54 am
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
Posts: 69
Joined: Wed Aug 28, 2013 2:47 am

Re: strange behavior of l=1 ridge for Procyon

Post by warrick » Mon Dec 02, 2019 5:47 am

mjoyce wrote:
Sun Dec 01, 2019 2:29 am
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.

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

Re: strange behavior of l=1 ridge for Procyon

Post by rhtownsend » Mon Dec 02, 2019 9:06 am

warrick wrote:
Mon Dec 02, 2019 5:47 am
mjoyce wrote:
Sun Dec 01, 2019 2:29 am
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

Post Reply